गुणवत्ता के लिए कौन जिम्मेदार है?

हे हबर!

हमारे पास एक नया महत्वपूर्ण विषय है - आईटी उत्पादों का उच्च गुणवत्ता वाला विकास। हाईलोड++ में हम अक्सर व्यस्त सेवाओं को तेज़ बनाने के बारे में बात करते हैं, और फ़्रंटएंड कॉन्फ़ में हम एक अच्छे उपयोगकर्ता इंटरफ़ेस के बारे में बात करते हैं जो धीमा नहीं होता है। हमारे पास नियमित रूप से परीक्षण के बारे में विषय होते हैं, और DevOpsConf में परीक्षण सहित विभिन्न प्रक्रियाओं के संयोजन के बारे में विषय होते हैं। लेकिन सामान्य तौर पर गुणवत्ता किसे कहा जा सकता है और इस पर व्यापक रूप से कैसे काम किया जाए, इसके बारे में नहीं।

आइए इसे ठीक करें क्वालिटीकॉन्फ - हम विकास के हर चरण में उपयोगकर्ता के लिए अंतिम उत्पाद की गुणवत्ता के बारे में सोचने की संस्कृति विकसित करेंगे। अपनी जिम्मेदारी के क्षेत्र पर ध्यान न देने और गुणवत्ता को केवल परीक्षकों से जोड़ने की आदत।

कट के नीचे हम कार्यक्रम समिति के प्रमुख, टिंकॉफ.बिजनेस में परीक्षण के प्रमुख, रूसी भाषी क्यूए समुदाय के निर्माता से बात करेंगे। अनास्तासिया असीवा-गुयेन क्यूए उद्योग की स्थिति और नए सम्मेलन के मिशन के बारे में।

- नास्तिया नमस्ते. कृपया अपने बारे में हमें बताएं।

अनास्तासिया: मैं एक बैंक में परीक्षण का प्रबंधन करता हूं, मैं एक बहुत बड़ी टीम के लिए जिम्मेदार हूं - हम 90 से अधिक लोग हैं। हमारे पास एक महत्वपूर्ण व्यावसायिक क्षेत्र है; हम कानूनी संस्थाओं के लिए पारिस्थितिकी तंत्र के लिए जिम्मेदार हैं।

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

मैं गुणवत्ता आश्वासन अनुशासन का प्रबल अनुयायी हूं। मैं इस बात के प्रति उदासीन नहीं हूं कि कौन से उत्पाद बनाए जाते हैं, कंपनी में, टीम में और सिद्धांत रूप में, विकास प्रक्रिया में गुणवत्ता का कैसे ध्यान रखा जाता है।

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

— आप गुणवत्ता आश्वासन और परीक्षण शब्दों का उपयोग करते हैं। औसत व्यक्ति की नज़र में, ये दोनों शब्द अक्सर ओवरलैप होते हैं। यदि आप गहराई से देखें तो वे किस प्रकार भिन्न हैं?

अनास्तासिया: बल्कि, वे अलग नहीं हैं. परीक्षण गुणवत्ता आश्वासन अनुशासन का हिस्सा है; यह एक प्रत्यक्ष गतिविधि है - तथ्य यह है कि मैं किसी चीज़ का परीक्षण कर रहा हूँ। वास्तव में परीक्षण कई प्रकार के होते हैं, और विभिन्न प्रकार के परीक्षण के लिए विभिन्न प्रकार के लोग जिम्मेदार होते हैं। लेकिन यहां रूस में, जब कंपनियों को परीक्षकों की आपूर्ति करने वाले आउटसोर्सरों की एक लहर सामने आई, तो परीक्षण को एक ही प्रकार तक सीमित कर दिया गया।

ज्यादातर मामलों में, वे केवल कार्यात्मक परीक्षण तक ही सीमित हैं: वे जांचते हैं कि डेवलपर्स ने जो कोड किया है वह विनिर्देश के अनुरूप है और बस इतना ही।

— कृपया हमें बताएं कि अन्य गुणवत्ता आश्वासन अनुशासन क्या हैं? परीक्षण के अलावा, यहां और क्या शामिल है?

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

परीक्षक अपनी भूमिका के प्रति अधिक जागरूक हो जाता है। वह समझता है कि उसका काम न केवल आवश्यकताओं के अनुपालन के लिए परीक्षण करना है, बल्कि आवश्यकताओं का परीक्षण करना, उत्पाद विशेषज्ञ से आने वाले फॉर्मूलेशन पर सवाल उठाना और ग्राहक की सभी अंतर्निहित आवश्यकताओं और अपेक्षाओं को प्रकट करना भी है। जब हम अपने ग्राहक को नई कार्यक्षमता प्रदान करते हैं, तो हमें वास्तव में उनकी अपेक्षाओं को पूरा करना चाहिए और उनके दर्द का समाधान करना चाहिए। यदि हम गुणवत्ता की सभी विशेषताओं के बारे में सोचें, तो ग्राहक संतुष्ट हो जाएगा और समझ जाएगा कि जिस कंपनी का उत्पाद वह उपयोग करता है वह वास्तव में उसके हितों की परवाह करती है, और "केवल एक सुविधा जारी करने के लिए" के सिद्धांत पर काम नहीं करती है।

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

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

— यह पता चला है कि गुणवत्ता लगभग सभी आसपास के विषयों के साथ जुड़ती है, जो चारों ओर की हर चीज़ पर एक रूपरेखा थोपती है?

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

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

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

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

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

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

पहला प्रश्न यह है कि उत्पाद जारी करने के बाद हम इन बगों से कैसे निपटेंगे? उदाहरण के लिए, हम तनाव पर कैसे प्रतिक्रिया करते हैं? यदि पेज लोड होने में 30 सेकंड से अधिक समय लगता है तो क्लाइंट बहुत खुश नहीं होगा।

यहीं पर शोषण शुरू होता है या, जैसा कि वे इसे अब कहते हैं, DevOps. वास्तव में, ये वे लोग हैं जो उत्पाद के पहले से ही उत्पादन में होने पर उसके संचालन के लिए जिम्मेदार हैं। इसमें विभिन्न प्रकार की निगरानी शामिल है। परीक्षण का एक उपप्रकार भी है - उत्पादन पर परीक्षण, जब हम खुद को रोलआउट से पहले किसी चीज़ का परीक्षण न करने और उत्पादन पर तुरंत परीक्षण करने की अनुमति देते हैं। यह बुनियादी ढांचे को व्यवस्थित करने के दृष्टिकोण से उपायों की एक श्रृंखला है जो आपको किसी घटना पर तुरंत प्रतिक्रिया देने, उसे प्रभावित करने और उसे ठीक करने की अनुमति देती है।

बुनियादी ढांचा भी महत्वपूर्ण है. अक्सर ऐसी स्थितियाँ होती हैं, जब परीक्षण के दौरान, यह सुनिश्चित करना असंभव होता है कि हमारे पास वास्तव में वह सब कुछ है जो हम ग्राहक को देना चाहते हैं। हम इसे उत्पादन में लाते हैं और गैर-स्पष्ट स्थितियों को पकड़ना शुरू करते हैं। और सब इसलिए क्योंकि परीक्षण में बुनियादी ढांचा उत्पादन में बुनियादी ढांचे के अनुरूप नहीं है। इससे एक नए प्रकार के परीक्षण की शुरुआत होती है - बुनियादी ढांचे का परीक्षण. ये विभिन्न कॉन्फ़िगरेशन, सेटिंग्स, डेटाबेस माइग्रेशन आदि हैं।

इससे सवाल उठता है - शायद टीम को कोड के रूप में बुनियादी ढांचे का उपयोग करने की आवश्यकता है।

मेरा मानना ​​है कि बुनियादी ढांचा सीधे उत्पाद की गुणवत्ता को प्रभावित करता है।

मुझे उम्मीद है कि सम्मेलन में वास्तविक मामले पर एक रिपोर्ट होगी। यदि आप अपने अनुभव से हमें यह बताने के लिए तैयार हैं कि कोड के रूप में बुनियादी ढांचा गुणवत्ता को कैसे प्रभावित करता है तो हमें लिखें। कोड के रूप में इंफ्रास्ट्रक्चर सभी सेटिंग्स की जांच करना और उन चीज़ों का परीक्षण करना आसान बनाता है जो अन्यथा संभव नहीं हैं। इसलिए, गुणवत्तापूर्ण उत्पाद विकसित करने की प्रक्रिया में ऑपरेशन भी शामिल है।

- विश्लेषण और दस्तावेज़ीकरण के बारे में क्या?

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

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

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

डेवलपर कीट नहीं हैं और जानबूझकर त्रुटियों वाला कोड नहीं लिखते हैं।

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

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

यहां एजाइल के दृष्टिकोण दिमाग में आते हैं - स्वीकृति मानदंड वाली उपयोगकर्ता कहानियां। यह उन टीमों के लिए अधिक लागू है जो छोटे पुनरावृत्तियों में विकसित होती हैं।

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

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

इसके अलावा एक और समस्या है. डिज़ाइन सिस्टम अब लोकप्रियता हासिल कर रहे हैं। वे प्रचार पर हैं, लेकिन उनसे होने वाले लाभ पूरी तरह से स्पष्ट नहीं हैं।

मेरी राय यह है कि डिज़ाइन सिस्टम, एक ओर, विकास को सरल बनाते हैं, लेकिन दूसरी ओर, वे इंटरफ़ेस पर बहुत सारे प्रतिबंध लगाते हैं।

परिणामस्वरूप, हम वह सुविधा नहीं बनाते जो ग्राहक चाहता है, बल्कि वह सुविधा बनाते हैं जो हमारे लिए सुविधाजनक है, क्योंकि हमारे पास पहले से ही कुछ निश्चित क्यूब्स हैं जिनसे हम इसे बना सकते हैं।

मुझे लगता है कि यह देखने और सोचने लायक विषय है कि क्या डिज़ाइन को आसान बनाने की कोशिश में हम वास्तव में क्लाइंट की समस्या का समाधान कर रहे हैं।

— गुणवत्ता आश्वासन से संबंधित आश्चर्यजनक संख्या में विषय हैं। क्या रूस में कोई सम्मेलन है जहां इन सब पर चर्चा हो सके?

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

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

मैं एक बड़ा विभाग चलाता हूं और बहुत सारे साक्षात्कार आयोजित करता हूं जो वास्तव में पूरे उद्योग की स्थिति के बारे में जानकारी प्रदान करते हैं। एक नियम के रूप में, हमारे लोग उद्यमों में काम करते हैं, और उनके पास जिम्मेदारी का एक स्पष्ट क्षेत्र है। विदेशी परियोजनाओं में काम करने वाले सहकर्मी विभिन्न प्रकार के परीक्षण का उपयोग करते हैं: वे स्वयं लोड परीक्षण, प्रदर्शन परीक्षण और यहां तक ​​​​कि कभी-कभी सुरक्षा परीक्षण भी कर सकते हैं, क्योंकि वे वास्तव में टीम को उत्पाद की गुणवत्ता सुनिश्चित करने में मदद करते हैं।

मैं चाहूंगा कि रूस के लोग भी यह सोचना शुरू करें कि उद्योग कार्यात्मक परीक्षण के साथ समाप्त नहीं होता है।

- इस उद्देश्य के लिए, हम एक नया सम्मेलन, क्वालिटीकॉन्फ आयोजित कर रहे हैं, जो एक अभिन्न अनुशासन के रूप में गुणवत्ता के लिए समर्पित है। इस विचार के बारे में और बताएं, सम्मेलन का मुख्य लक्ष्य क्या है?

अनास्तासिया: हम गुणवत्तापूर्ण उत्पाद बनाने में रुचि रखने वाले लोगों का एक समुदाय बनाना चाहते हैं। एक ऐसा मंच प्रदान करें जहां वे आ सकें, रिपोर्ट सुन सकें और सम्मेलन के बाद इस विशिष्ट समझ के साथ जा सकें कि गुणवत्ता में सुधार के लिए क्या बदलाव करने की आवश्यकता है।

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

हर कोई इस तथ्य के बारे में नहीं सोचता है कि खराब वास्तुकला के साथ खराब लिखा गया, कम गुणवत्ता वाला कोड परियोजना के लिए बड़ी समस्याओं का खतरा है। वे त्रुटियों की कीमत के बारे में नहीं सोचते हैं, कि उत्पादन में आने वाले बग के परिणामस्वरूप कंपनी और टीम को बड़ी लागत चुकानी पड़ सकती है। इस बारे में सोचने की कोई संस्कृति नहीं है. मैं चाहता हूं कि हम सम्मेलन में इसका वितरण शुरू करें।

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

— क्या आप परीक्षण और टूल से संबंधित विषयों पर सीधे बात करने की योजना बना रहे हैं?

अनास्तासिया: मैं मानता हूं कि टूल्स के बारे में रिपोर्टें होंगी। ऐसे काफी सार्वभौमिक उपकरण हैं जिनकी मदद से कंपनियां और टीमें उत्पाद को प्रभावित कर सकती हैं।

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

हमारे पास निश्चित रूप से टूल के लिए टूल के बारे में रिपोर्ट नहीं होगी। कार्यक्रम में शामिल सभी रिपोर्टें एक समान लक्ष्य से एकजुट होंगी।

— आप किस बारे में बात कर रहे हैं, आप सम्मेलन के अतिथि के रूप में किसे देखते हैं, इसमें किसकी रुचि होगी?

अनास्तासिया: हमारे पास उन डेवलपर्स के लिए रिपोर्टें होंगी जो अपने प्रोजेक्ट, उत्पाद, सिस्टम के भाग्य की परवाह करते हैं। इसी तरह, यह परीक्षकों के लिए दिलचस्प होगा और मुझे ऐसा लगता है, खासकर प्रबंधकों के लिए। प्रबंधकों से मेरा तात्पर्य ऐसे लोगों से है जो निर्णय लेते हैं और किसी उत्पाद, प्रणाली, टीम के भाग्य और विकास को भी प्रभावित कर सकते हैं।

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

मुझे लगता है कि मुख्य मानदंड यह समझना है कि गुणवत्ता में कुछ गड़बड़ है और हम इसे प्रभावित करना चाहते हैं। हम शायद उन लोगों तक नहीं पहुंच पाएंगे जो सोचते हैं कि यह पहली बार में ही काम करेगा।

— क्या आपको लगता है कि संपूर्ण उद्योग न केवल परीक्षण के बारे में, बल्कि गुणवत्ता की संस्कृति के बारे में बात करने के लिए तैयार है?

अनास्तासिया: मुझे लगता है कि मैं परिपक्व हो गया हूं. अब कई कंपनियां पारंपरिक वॉटरफॉल दृष्टिकोण से हटकर एजाइल की ओर बढ़ रही हैं। ग्राहक फोकस है, टीमों में लोग वास्तव में यह सोचना शुरू कर रहे हैं कि गुणवत्तापूर्ण उत्पाद कैसे बनाया जाए। यहां तक ​​कि उद्यम कंपनियां भी गुणवत्ता में सुधार पर दोबारा ध्यान केंद्रित कर रही हैं।

समुदाय में उठ रहे अनुरोधों की संख्या को देखते हुए, मेरा मानना ​​है कि अब समय आ गया है। बेशक, मुझे यकीन नहीं है कि यह एक बड़े पैमाने की क्रांति होगी, लेकिन मैं चाहूंगा कि चेतना में यह क्रांति हो।

- मान गया! हम संस्कृति स्थापित करेंगे और चेतना बदलेंगे।

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

से कनेक्ट बात करना, जिसमें हम गुणवत्ता के मुद्दों और सम्मेलन पर चर्चा करते हैं, सदस्यता लेते हैं टेलीग्राम चैनलकार्यक्रम समाचारों से अपडेट रहने के लिए।

स्रोत: www.habr.com