गुणस्तरको जिम्मेवारी कसको ?

हे हाबर!

हामीसँग नयाँ महत्त्वपूर्ण विषय छ - आईटी उत्पादनहरूको उच्च-गुणस्तर विकास। HighLoad++ मा हामी प्राय: कसरी व्यस्त सेवाहरू छिटो बनाउने भन्ने बारे कुरा गर्छौं, र Frontend Conf मा हामी एक राम्रो प्रयोगकर्ता इन्टरफेसको बारेमा कुरा गर्छौं जुन ढिलो हुँदैन। हामीसँग नियमित रूपमा परीक्षणको बारेमा विषयहरू छन्, र DevOpsConf परीक्षण सहित विभिन्न प्रक्रियाहरू संयोजन गर्ने बारे। तर के बारे मा सामान्य मा गुणस्तर भनिन्छ, र यसलाई व्यापक रूपमा कसरी काम गर्न - छैन।

यसलाई द्वारा ठीक गरौं QualityConf - हामी विकासको हरेक चरणमा प्रयोगकर्ताको लागि अन्तिम उत्पादनको गुणस्तरको बारेमा सोच्ने संस्कृति विकास गर्नेछौं। आफ्नो जिम्मेवारी क्षेत्रमा ध्यान केन्द्रित नगर्ने बानी, र गुणस्तर मात्र होइन परीक्षकहरूसँग जोड्ने।

कट तल हामी कार्यक्रम समितिको प्रमुख, Tinkoff.Business मा परीक्षण प्रमुख, रूसी भाषा बोल्ने QA समुदायको सिर्जनाकर्तासँग कुरा गर्नेछौं। Anastasia Aseeva-Nguyen QA उद्योगको अवस्था र नयाँ सम्मेलनको मिशनको बारेमा।

- Nastia नमस्कार। कृपया हामीलाई आफ्नो बारेमा बताउनुहोस्।

Anastasia: म बैंकमा परीक्षणको नेतृत्व गर्छु र धेरै ठूलो टोलीको लागि जिम्मेवार छु—हामी ९० जनाभन्दा बढी छौं। हामीसँग महत्त्वपूर्ण व्यापार लाइन छ; हामी कानूनी संस्थाहरूको लागि इकोसिस्टमको लागि जिम्मेवार छौं।

मैले मेकानिक्स र गणित अध्ययन गरें र सुरुमा प्रोग्रामर बन्न चाहन्थे। तर जब मैले एक रोचक प्रस्ताव प्राप्त गरें, मैले आफैलाई परीक्षकको रूपमा प्रयास गर्ने निर्णय गरे। अचम्मको कुरा, यो मेरो कल भएको थियो। अब म यो उद्योगमा मेरो सबै काम देख्छु।

म गुणस्तर आश्वासन अनुशासनको कट्टर अनुयायी हुँ। म के उत्पादनहरू सिर्जना गरिन्छन्, कम्पनीमा, टोलीमा, र सिद्धान्तमा, विकास प्रक्रियामा गुणस्तर कसरी व्यवहार गरिन्छ भन्ने बारे ख्याल राख्छु।

यो मलाई स्पष्ट छ यस दिशामा समुदाय पर्याप्त परिपक्व छैन, कम्तिमा रूस मा। हामी सधैं यो बुझ्दैनौं कि गुणस्तर आश्वासन भनेको आवश्यकताहरूको अनुपालनको लागि आवेदन परीक्षण गर्ने तथ्य मात्र होइन। म यो अवस्था परिवर्तन गर्न चाहन्छु।

- तपाईले गुणस्तर आश्वासन र परीक्षण शब्दहरू प्रयोग गर्नुहुन्छ। औसत व्यक्तिको नजरमा, यी दुई सर्तहरू प्राय: ओभरल्याप हुन्छन्। यदि तपाइँ गहिरो खन्नुहुन्छ भने तिनीहरू कसरी फरक हुन्छन्?

अनास्तासिया: बरु, तिनीहरू फरक छैनन्। परीक्षण गुणस्तर आश्वासन अनुशासनको अंश हो, यो प्रत्यक्ष गतिविधि हो - यो तथ्य हो कि म केहि परीक्षण गर्दैछु। त्यहाँ वास्तवमा धेरै प्रकारका परीक्षणहरू छन्, र विभिन्न प्रकारका परीक्षणहरूका लागि विभिन्न व्यक्तिहरू जिम्मेवार छन्। तर यहाँ रसियामा, जब कम्पनीहरूलाई परीक्षकहरू आपूर्ति गर्ने आउटसोर्सरहरूको लहर देखा पर्‍यो, परीक्षण एकल प्रकारमा घटाइयो।

धेरै जसो केसहरूमा, तिनीहरू केवल कार्यात्मक परीक्षणमा सीमित छन्: तिनीहरूले जाँच गर्छन् कि विकासकर्ताहरूले कोड गरेको विनिर्देशको साथ अनुपालन गर्दछ र यो हो।

- कृपया हामीलाई भन्नुहोस् कि अन्य गुणस्तर आश्वासन अनुशासनहरू के छन्? यहाँ परीक्षण बाहेक अरू के समावेश छ?

Anastasia: गुणस्तर आश्वासन, पहिलो र प्रमुख, गुणस्तर उत्पादन सिर्जना गर्ने बारे हो। त्यो हो, हामी आफैलाई सोध्छौं कि हाम्रो उत्पादनको गुणस्तर विशेषताहरू हुनुपर्छ। तदनुसार, यदि हामीले यो बुझ्यौं भने, हामी तुलना गर्न सक्छौं कि यी गुणस्तर विशेषताहरूलाई कसले प्रभाव पार्छ। फरक पर्दैन, विकासकर्ता, परियोजना प्रबन्धक वा उत्पादन विशेषज्ञ एक व्यक्ति हो जसले उत्पादनको विकास, यसको ब्याकलग, र यसको रणनीतिलाई प्रभाव पार्छ।

परीक्षक आफ्नो भूमिकाको बारेमा बढी सचेत हुन्छ। उसले बुझ्छ कि उसको काम केवल आवश्यकताहरूको अनुपालनको लागि परीक्षण मात्र होइन, तर आवश्यकताहरू परीक्षण गर्ने, उत्पादन विशेषज्ञबाट आएका सूत्रहरूमा प्रश्न गर्ने, र ग्राहकका सबै निहित आवश्यकताहरू र अपेक्षाहरू प्रकट गर्ने। जब हामी हाम्रो ग्राहकलाई नयाँ कार्यक्षमता प्रदान गर्छौं, हामीले साँच्चै तिनीहरूको अपेक्षाहरू पूरा गर्नुपर्छ र तिनीहरूको पीडा समाधान गर्नुपर्छ। यदि हामीले गुणस्तरका सबै विशेषताहरू बारे सोच्यौं भने, ग्राहक सन्तुष्ट हुनेछन् र बुझ्नेछन् कि कम्पनी जसको उत्पादन उसले प्रयोग गर्छ उसले वास्तवमा आफ्नो रुचिहरूको ख्याल राख्छ र "केवल एक सुविधा जारी गर्ने" सिद्धान्तमा काम गरिरहेको छैन।

- तपाईंले भर्खरै वर्णन गर्नुभएको कुरा उत्पादन विशेषज्ञको कार्य हो जस्तो देखिन्छ। यो, सिद्धान्तमा, परीक्षणको बारेमा होइन र गुणस्तरको बारेमा होइन - यो सामान्यतया उत्पादन व्यवस्थापनको बारेमा हो, होइन?

Anastasia: सहित। गुणस्तर आश्वासन एक अनुशासन होइन जसको लागि एक विशिष्ट व्यक्ति जिम्मेवार छ। अब परीक्षण मा एक लोकप्रिय दिशा छ, एक दृष्टिकोण भनिन्छ चुस्त परीक्षण। यसको परिभाषाले स्पष्ट रूपमा बताउँछ कि यो परीक्षणको लागि टोली दृष्टिकोण हो, जसमा अभ्यासहरूको निश्चित सेट समावेश छ। यो दृष्टिकोण लागू गर्नको लागि सम्पूर्ण टोली जिम्मेवार छ; टोलीमा परीक्षक हुनु आवश्यक पनि छैन। सम्पूर्ण टोली ग्राहकलाई मूल्य प्रदान गर्न र मूल्य ग्राहकको अपेक्षाहरू पूरा गर्ने सुनिश्चित गर्नमा केन्द्रित छ।

- यो बाहिर जान्छ कि गुणस्तर लगभग सबै वरपरका अनुशासनहरु संग प्रतिच्छेदन गर्दछ, वरपर सबै मा एक ढाँचा थोपा?

Anastasia: सहि हो । जब हामी तथ्यको बारेमा सोच्दछौं कि हामी गुणस्तर उत्पादन सिर्जना गर्न चाहन्छौं, हामी गुणस्तरका विभिन्न विशेषताहरूको बारेमा सोच्न थाल्छौं। उदाहरणका लागि, हामीले साँच्चै हाम्रो ग्राहकलाई चाहिने सुविधा बनाएका छौं भनेर कसरी जाँच गर्ने।

यो जहाँ यस प्रकारको परीक्षण आउँछ: UAT (प्रयोगकर्ता स्वीकृति परीक्षण)। दुर्भाग्यवश, यो रूसमा विरलै अभ्यास गरिन्छ, तर कहिलेकाहीँ अन्तिम ग्राहकको लागि डेमोको रूपमा SCRUM टोलीहरूमा उपस्थित हुन्छ। यो विदेशी कम्पनीहरूमा परीक्षणको एकदम सामान्य प्रकार हो। सबै ग्राहकहरूको लागि कार्यक्षमता खोल्नु अघि, हामी पहिले UAT गर्छौं, त्यो हो, हामी अन्तिम प्रयोगकर्तालाई परीक्षण गर्न र तुरुन्तै प्रतिक्रिया प्रदान गर्दछौं कि उत्पादनले वास्तवमा अपेक्षाहरू पूरा गर्दछ र पीडा समाधान गर्दछ। यो पछि मात्र अन्य सबै ग्राहकहरु मा स्केलिंग सम्भव छ।

त्यो हो, हामी व्यापारमा फोकस गर्छौं, अन्तिम ग्राहकमा, तर एकै समयमा प्रविधिको बारेमा नबिर्सनुहोस्। उत्पादनको गुणस्तर पनि प्रविधिमा धेरै निर्भर गर्दछ। यदि हामीसँग खराब वास्तुकला छ भने, हामी चाँडै सुविधाहरू जारी गर्न र ग्राहकको अपेक्षाहरू पूरा गर्न सक्षम हुने छैनौं। मापन गर्ने प्रयास गर्दा धेरै बगहरू हुन सक्छन्, वा रिफ्याक्टर गर्ने प्रयास गर्दा, हामीले केही तोड्न सक्छौं। यी सबैले ग्राहकको सन्तुष्टिलाई असर गर्नेछ।

यस दृष्टिकोणबाट, वास्तुकला यस्तो हुनुपर्छ कि हामीले सफा कोड लेख्न सक्छौं जसले हामीलाई चाँडै परिवर्तनहरू गर्न अनुमति दिन्छ र हामी सबै कुरा तोड्ने डराउँदैनौं। हामीसँग धेरै विरासत भएको कारणले मात्र संशोधन पुनरावृत्तिहरू धेरै महिनाहरू नफर्कने सुनिश्चित गर्न, हामीले लामो परीक्षण चरणहरू गर्न आवश्यक छ।

- कुलमा, विकासकर्ताहरू, आर्किटेक्टहरू, उत्पादन वैज्ञानिकहरू, उत्पादन प्रबन्धकहरू, र परीक्षकहरू पहिले नै संलग्न छन्। गुणस्तर आश्वासन प्रक्रियामा अरू को संलग्न छन्?

Anastasia: अब कल्पना गरौं कि हामीले पहिले नै ग्राहकलाई सुविधा प्रदान गरिसकेका छौं। स्पष्ट रूपमा, उत्पादनको गुणस्तर पहिले नै उत्पादनमा हुँदा पनि निगरानी गर्न आवश्यक छ। यस चरणमा, गैर-स्पष्ट परिदृश्यहरू, तथाकथित बगहरू, देखा पर्न सक्छन्।

पहिलो प्रश्न यो हो कि हामीले उत्पादन जारी गरिसकेपछि हामी यी बगहरूसँग कसरी व्यवहार गर्छौं? हामी, उदाहरणका लागि, तनावमा कसरी प्रतिक्रिया गर्छौं? यदि पृष्ठ लोड हुन 30 सेकेन्ड भन्दा बढी लाग्छ भने ग्राहक धेरै खुसी हुनेछैन।

यो जहाँ शोषण खेलमा आउँछ, वा तिनीहरूले यसलाई अहिले भन्छन्। DevOps। वास्तवमा, यी मानिसहरू हुन् जो उत्पादन सञ्चालन गर्न जिम्मेवार छन् जब यो पहिले नै उत्पादनमा छ। यसमा विभिन्न प्रकारका अनुगमनहरू समावेश छन्। त्यहाँ पनि परीक्षणको एक उपप्रकार छ - उत्पादनमा परीक्षण, जब हामी आफैलाई रिलीज गर्नु अघि केहि परीक्षण गर्न र उत्पादनमा तुरुन्तै परीक्षण गर्न अनुमति दिन्छौं। यो पूर्वाधारलाई व्यवस्थित गर्ने दृष्टिकोणबाट गतिविधिहरूको एक श्रृंखला हो जसले तपाईंलाई घटनामा द्रुत प्रतिक्रिया दिन, यसलाई प्रभाव पार्न र सुधार गर्न अनुमति दिन्छ।

पूर्वाधार पनि महत्त्वपूर्ण छ। त्यहाँ प्रायः परिस्थितिहरू हुन्छन् जब, परीक्षणको क्रममा, हामीसँग वास्तवमै ग्राहकलाई दिन चाहेको सबै कुरा छ भनेर सुनिश्चित गर्न असम्भव हुन्छ। हामी यसलाई उत्पादनमा रोल आउट गर्छौं र गैर-स्पष्ट परिस्थितिहरू समात्न थाल्छौं। र सबै किनभने परीक्षणमा पूर्वाधार उत्पादनमा पूर्वाधारसँग मेल खाँदैन। यसले नयाँ प्रकारको परीक्षणको नेतृत्व गर्दछ - पूर्वाधार परीक्षण। यसमा विभिन्न कन्फिगरेसनहरू, सेटिङहरू, डाटाबेस माइग्रेसनहरू, आदि समावेश छन्।

यसले प्रश्न उठाउँछ - सायद टोलीले कोडको रूपमा पूर्वाधार प्रयोग गर्न आवश्यक छ।

मलाई विश्वास छ कि पूर्वाधारले उत्पादनको गुणस्तरलाई प्रत्यक्ष असर गर्छ।

मलाई आशा छ कि सम्मेलनमा वास्तविक मामला संग एक रिपोर्ट हुनेछ। कोडको रूपमा पूर्वाधारले गुणस्तरलाई कसरी असर गर्छ भन्ने कुरा आफ्नो अनुभवबाट बताउन तयार हुनुहुन्छ भने हामीलाई लेख्नुहोस्। कोडको रूपमा पूर्वाधारले सबै सेटिङहरू जाँच गर्न र अन्यथा सम्भव नहुने चीजहरूको परीक्षण गर्न सजिलो बनाउँछ। तसर्थ, सञ्चालन पनि गुणस्तरीय उत्पादन विकास गर्ने प्रक्रियामा संलग्न छ।

- विश्लेषण र कागजातको बारेमा के हो?

Anastasia: यो उद्यम प्रणालीहरूमा बढी लागू हुन्छ। जब हामी उद्यमको बारेमा कुरा गर्छौं, विश्लेषकहरू र प्रणाली विश्लेषकहरू जस्ता व्यक्तिहरू तुरुन्तै दिमागमा आउँछन्। तिनीहरूलाई कहिलेकाहीँ प्राविधिक लेखकहरू भनिन्छ। तिनीहरूले एक स्पेसिफिकेशन लेख्न र यसलाई पूरा गर्न कार्य प्राप्त गर्छन्, उदाहरणका लागि, एक महिनाको लागि।

यो बारम्बार प्रमाणित भएको छ कि त्यस्ता कागजातहरू लेख्दा धेरै लामो विकास पुनरावृत्तिहरू र सुधारको लामो पुनरावृत्तिहरू हुन्छन्, किनभने परीक्षण प्रक्रियाको क्रममा बगहरू पहिचान हुन्छन् र फिर्ताहरू सुरु हुन्छन्। नतिजाको रूपमा, त्यहाँ धेरै लूपहरू छन् जसले विकासको लागत बढाउँछ। थप रूपमा, यसले कमजोरीहरू परिचय गर्न सक्छ। हामीले सन्दर्भ कोड लेखेको जस्तो देखिन्छ, तर त्यसपछि हामीले परिवर्तनहरू गर्यौं जसले पूर्ण रूपमा सोचेको वास्तुकलालाई तोड्छ।

नतिजाको रूपमा, नतिजा धेरै उच्च-गुणस्तरको उत्पादन होइन, किनभने प्याचहरू पहिले नै वास्तुकलामा देखा परेका छन्, केही स्थानहरूमा कोड पर्याप्त रूपमा परीक्षणहरू कभर गरिएको छैन, किनभने समय सीमा समाप्त हुँदैछ, सबै बगहरू छिटो बन्द गर्न आवश्यक छ। र सबै किनभने मूल स्पेसिफिकेशनले कार्यान्वयन गर्न आवश्यक सबै बिन्दुहरूलाई ध्यानमा राखेन।

विकासकर्ताहरू कीटहरू होइनन् र उद्देश्यमा त्रुटिहरूसँग कोड लेख्दैनन्।

यदि हामीले प्रारम्भिक रूपमा सबै आवश्यक बिन्दुहरू समेट्ने स्पेसिफिकेशन मार्फत सोचेका थियौं भने, त्यसपछि सबै कुरा आवश्यक रूपमा लागू हुने थियो। तर यो एक यूटोपिया हो।

यो एक उत्तम 100-पृष्ठ विशिष्टता लेख्न सम्भवतः असम्भव छ। त्यसैले होला कागजात लेख्ने वैकल्पिक तरिकाहरू बारे सोच्न आवश्यक छ, विशिष्टताहरू, कार्य कथनहरू जसले हामीलाई विकासकर्ताले ठ्याक्कै के आवश्यक छ भन्ने कुरा सुनिश्चित गर्न नजिक ल्याउनेछ।

यो जहाँ चपल दृष्टिकोण दिमागमा आउँछ - स्वीकृति मापदण्डको साथ प्रयोगकर्ता कथाहरू। यो सानो पुनरावृत्तिमा विकास गर्ने टोलीहरूको लागि बढी लागू हुन्छ।

- उपयोगिता परीक्षण, उत्पादन उपयोगिता, डिजाइनको बारेमा के हो?

Anastasia: यो एक धेरै महत्त्वपूर्ण बिन्दु हो, किनभने टोलीमा डिजाइनरहरू छन्। प्रायः, डिजाइनरहरू सेवाको रूपमा प्रयोग गरिन्छ - या त डिजाइन विभाग वा आउटसोर्स डिजाइनर द्वारा। त्यहाँ अक्सर परिस्थितिहरू छन् जहाँ यो देखिन्छ कि डिजाइनरले उत्पादन वैज्ञानिकको कुरा सुन्यो र उसले के बुझ्यो। तर जब हामी पुनरावृत्ति सुरु गर्छौं, यो बाहिर जान्छ कि वास्तवमा के गरिएको थियो जुन अपेक्षा गरिएको थिएन: डिजाइनरले केहि बिर्स्यो, व्यवहार मार्फत पूर्ण रूपमा सोचेन, किनभने उनी टोलीमा थिएनन् र सन्दर्भमा थिएनन्, वा अगाडि। -अन्त विकासकर्ताले यसको लेआउट पूर्ण रूपमा बुझेन। यसले धेरै पुनरावृत्तिहरू लिन सक्छ किनभने त्यहाँ डिजाइनको अगाडि-अन्त विकासकर्ताको बुझाइमा समस्या छ।

साथै त्यहाँ अर्को समस्या छ। डिजाइन प्रणालीहरू अब लोकप्रियता प्राप्त गर्दै छन्। तिनीहरू हाइपमा छन्, तर तिनीहरूबाट लाभहरू पूर्ण रूपमा स्पष्ट छैनन्।

म यो रायको सामना गरिरहेको छु कि डिजाइन प्रणालीहरू, एकातिर, विकासलाई सरल बनाउँदछ, तर अर्कोतर्फ, तिनीहरूले इन्टरफेसमा धेरै प्रतिबन्धहरू लगाउँछन्।

नतिजाको रूपमा, हामी ग्राहकले चाहेको सुविधा बनाउँदैनौं, तर हाम्रो लागि सुविधाजनक छ, किनभने हामीसँग पहिले नै निश्चित क्यूबहरू छन् जसबाट हामी यसलाई बनाउन सक्छौं।

मलाई लाग्छ कि यो यस विषयमा ध्यान दिन र डिजाइन कार्यलाई सरल बनाउने प्रयासमा हामी वास्तवमा ग्राहकको पीडा समाधान गर्दैछौं कि भनेर सोच्न लायक छ।

- गुणस्तर आश्वासनसँग सम्बन्धित विषयहरूको आश्चर्यजनक संख्याहरू छन्। के रूस मा एक सम्मेलन छ जहाँ ती सबै छलफल गर्न सकिन्छ?

Anastasia: त्यहाँ सबैभन्दा पुरानो परीक्षण सम्मेलन हो, जुन यस वर्ष 25 औं पटक आयोजित हुनेछ र गुणस्तर आश्वासन सम्मेलन SQA दिन भनिन्छ। यसले मुख्यतया कार्यात्मक परीक्षकहरूको लागि उपकरणहरू र विशिष्ट परीक्षण दृष्टिकोणहरू छलफल गर्दछ। एक नियमको रूपमा, SQA दिनहरूमा रिपोर्टहरूले परीक्षकहरूको जिम्मेवारीको क्षेत्रमा विशेष क्षेत्रहरूको गहिरो जाँच गर्दछ, तर जटिल गतिविधिहरू होइन।

यसले विभिन्न उपकरणहरू र दृष्टिकोणहरू बुझ्नमा धेरै मद्दत गर्दछ, कसरी डाटाबेसहरू, APIs, आदि परीक्षण गर्ने। तर एकै समयमा, एकतर्फ, यसले राम्रो उत्पादनको निर्माणमा परीक्षण मात्र भन्दा बढी समावेश गर्न उत्प्रेरित गर्दैन। अर्कोतर्फ, परीक्षकहरू उत्पादनको विश्वव्यापी लक्ष्य र यसको व्यापारिक घटकको बारेमा सोच्नको लागि प्रक्रियामा थप संलग्न हुँदैनन्।

म एक ठूलो विभाग चलाउँछु र धेरै अन्तर्वार्ताहरू सञ्चालन गर्छु, जसले वास्तवमा सम्पूर्ण उद्योगको अवस्थाको बारेमा अन्तर्दृष्टि प्रदान गर्दछ। नियमको रूपमा, हाम्रा केटाहरू उद्यममा काम गर्छन्, र तिनीहरूसँग जिम्मेवारीको स्पष्ट क्षेत्र छ। विदेशी परियोजनाहरूमा काम गर्ने सहकर्मीहरूले विभिन्न प्रकारका परीक्षणहरू प्रयोग गर्छन्: तिनीहरू आफैले लोड परीक्षण, कार्यसम्पादन परीक्षण, र कहिलेकाहीं सुरक्षा परीक्षण पनि गर्न सक्छन्, किनभने तिनीहरूले टोलीलाई वस्तुको गुणस्तर सुनिश्चित गर्न मद्दत गर्छन्।

म चाहन्छु कि रूसका केटाहरूले पनि यस तथ्यको बारेमा सोच्न थाले कि उद्योग कार्यात्मक परीक्षणको साथ समाप्त हुँदैन।

— यस उद्देश्यका लागि, हामीले एउटा नयाँ सम्मेलन, QualityConf आयोजना गर्दैछौं, जुन गुणस्तरमा अभिन्न अनुशासनको रूपमा समर्पित छ। विचारको बारेमा थप बताउनुहोस्, सम्मेलनको मुख्य लक्ष्य के हो?

Anastasia: हामी गुणस्तरीय उत्पादनहरू बनाउन रुचि राख्ने मानिसहरूको समुदाय सिर्जना गर्न चाहन्छौं। एक प्लेटफर्म प्रस्ताव गर्नुहोस् जहाँ तिनीहरू आउन सक्छन्, रिपोर्टहरू सुन्न र तिनीहरूले गुणस्तर सुधार गर्न के परिवर्तन गर्न आवश्यक छ भन्ने एक विशिष्ट बुझाइको साथ सम्मेलन छोड्नुहोस्।

आजकल म प्रायः परीक्षण र गुणस्तरमा समस्या हुँदा के गर्ने भनेर परामर्शबाट अनुरोध सुन्छु। जब तपाइँ टोलीहरूसँग कुराकानी गर्न सुरु गर्नुहुन्छ, तपाइँले देख्नुहुन्छ कि समस्या परीक्षकहरू आफैंमा होइन, तर प्रक्रियालाई संरचित गर्ने तरिकामा। उदाहरणका लागि, जब विकासकर्ताहरूले विश्वास गर्छन् कि तिनीहरू कोड लेख्नका लागि मात्र जिम्मेवार छन्, तिनीहरूको जिम्मेवारी ठ्याक्कै समाप्त हुन्छ जब तिनीहरूले कार्यलाई परीक्षणमा स्थानान्तरण गर्छन्।

सबैले यस तथ्यको बारेमा सोच्दैनन् कि खराब लेखिएको, खराब वास्तुकलाको साथ कम गुणस्तरको कोडले परियोजनाको लागि ठूलो समस्यालाई धम्की दिन्छ। तिनीहरू त्रुटिहरूको लागतको बारेमा सोच्दैनन्, कि उत्पादनमा समाप्त हुने बगहरूले कम्पनी र टोलीको लागि ठूलो लागत निम्त्याउन सक्छ। यसबारे सोच्ने संस्कृति छैन । म यसलाई सम्मेलनमा वितरण सुरु गर्न चाहन्छु।

म बुझ्छु कि यो नवीनता होइन। एडवर्ड डेमिङ, गुणस्तरको 14 सिद्धान्तका लेखक, गत शताब्दीमा त्रुटिको लागतको बारेमा लेखे। अनुशासनको रूपमा गुणस्तर आश्वासन यस पुस्तकमा आधारित छ, तर दुर्भाग्यवश, आधुनिक विकासले यसको बारेमा बिर्सन्छ।

- के तपाइँ परीक्षण र उपकरणहरूको बारेमा सिधै विषयहरूमा छुने योजना बनाउनुहुन्छ?

Anastasia: म स्वीकार गर्छु कि त्यहाँ उपकरणहरूको बारेमा रिपोर्टहरू हुनेछन्। त्यहाँ धेरै विश्वव्यापी उपकरणहरू छन् जसको साथ कम्पनीहरू र टोलीहरूले उत्पादनलाई प्रभाव पार्न सक्छन्।

सबै रिपोर्टहरू विश्वव्यापी रूपमा एउटै साझा मिशनद्वारा एकजुट हुनेछन्: दर्शकहरूलाई यो दृष्टिकोण, उपकरण, विधि, प्रक्रिया, परीक्षणको प्रकारको मद्दतले हामीले उत्पादनको गुणस्तरलाई प्रभाव पारेका छौं र ग्राहकको जीवनमा सुधार गरेका छौं।

हामीसँग निश्चित रूपमा उपकरणको लागि उपकरणको बारेमा रिपोर्टहरू हुनेछैनन्। कार्यक्रममा समावेश सबै प्रतिवेदनहरू साझा लक्ष्यद्वारा एकताबद्ध हुनेछन्।

- तपाई के कुरा गर्दै हुनुहुन्छ, सम्मेलनको अतिथिको रूपमा कसलाई देख्नुहुन्छ भन्नेमा कसलाई चासो हुनेछ?

Anastasia: हामीसँग विकासकर्ताहरूका लागि रिपोर्टहरू हुनेछन् जसले आफ्नो परियोजना, उत्पादन, प्रणालीको भाग्यको बारेमा ख्याल राख्छन्। त्यस्तै गरी, यो परीक्षकहरूको लागि चासोको हुनेछ र, यो मलाई लाग्छ, विशेष गरी प्रबन्धकहरूलाई। प्रबन्धकहरू द्वारा, मेरो मतलब ती व्यक्तिहरू हुन् जसले निर्णयहरू गर्छन् र उत्पादन, प्रणाली, टोली, अन्य चीजहरू बीचको भाग्य र विकासलाई प्रभाव पार्न सक्छन्।

यी मानिसहरू हुन् जसले उत्पादन वा प्रणालीको गुणस्तर कसरी सुधार गर्ने भनेर सोच्छन्। हाम्रो सम्मेलनमा, तिनीहरूले उपायहरूको विभिन्न सेटहरूको बारेमा सिक्नेछन् र तिनीहरूमा अहिले के गलत छ र के परिवर्तन गर्न आवश्यक छ भनेर बुझ्न सक्षम हुनेछन्।

मलाई लाग्छ कि मुख्य मापदण्ड भनेको गुणस्तरमा केहि गलत छ भनेर बुझ्नु हो र यसलाई प्रभाव पार्न चाहन्छ। हामी सायद यो पहिलो पटक हुनेछ भन्ने सोच्ने मानिसहरूमा पुग्न सक्षम हुनेछैनौं।

- के तपाईलाई लाग्छ कि उद्योग समग्रमा परीक्षणको बारेमा मात्र होइन, तर गुणस्तरको संस्कृतिको बारेमा कुरा गर्न परिपक्व छ?

Anastasia: म परिपक्व भएँ भन्ने विश्वास गर्छु। अब धेरै कम्पनीहरू परम्परागत झरना दृष्टिकोणबाट टाढा एगिल तर्फ सर्दै छन्। त्यहाँ क्लाइन्टमा फोकस छ, टोलीका मानिसहरूले वास्तवमै गुणस्तर उत्पादन कसरी सिर्जना गर्ने भन्ने बारे सोच्न थालेका छन्। उद्यमशील कम्पनीहरूले पनि गुणस्तर सुधारमा ध्यान दिइरहेका छन्।

समुदायमा उठ्ने अनुरोधहरूको संख्याको आधारमा, मलाई विश्वास छ कि यो समय हो। अवश्य पनि, म निश्चित छैन कि यो ठूलो स्तरको क्रान्ति हुनेछ, तर म यो क्रान्ति चेतनामा होस् भन्ने चाहन्छु।

- सहमत! संस्कृतिको जगेर्ना र चेतना परिवर्तन गर्नेछौं ।

आईटी उत्पादनहरूको उच्च गुणस्तरको विकासमा सम्मेलन QualityConf हुनेछ मस्कोमा जुन 7 मा। तपाईलाई थाहा छ कुन चरणहरूले उच्च-गुणस्तरको उत्पादन बनाउँछ, हामीसँग उत्पादनमा बगहरू सफलतापूर्वक लड्ने केसहरू छन्, हामीले आफ्नै अभ्यासमा लोकप्रिय विधिहरू परीक्षण गरेका छौं - हामीलाई तपाईंको अनुभव चाहिन्छ। पठाउनुहोस् आफ्नो मे 1 सम्म आवेदन, र कार्यक्रम समितिले सम्मेलनको समग्र अखण्डताको लागि विषयवस्तुलाई केन्द्रित गर्न मद्दत गर्नेछ।

जडान गर्नुहोस् कुराकानी, जसमा हामी गुणस्तर मुद्दाहरू र सम्मेलनमा छलफल गर्छौं, सदस्यता लिनुहोस् टेलिग्राम च्यानलकार्यक्रम समाचार संग अद्यावधिक राख्न।

स्रोत: www.habr.com