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

नमस्कार, हेब्र!

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

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

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



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

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

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

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

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

- आप गुणवत्ता आश्वासन और परीक्षण शब्द का उपयोग करते हैं। औसत की दृष्टि में, ये दोनों शब्द बहुत बार प्रतिच्छेद करते हैं। यदि आप गहरी खुदाई करते हैं तो वे कैसे भिन्न होते हैं?

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

ज्यादातर मामलों में, वे केवल कार्यात्मक परीक्षण तक ही सीमित हैं: वे सत्यापित करते हैं कि डेवलपर्स ने जो संकलित किया है वह विनिर्देशन और उस सभी से मिलता है।

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

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

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

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

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

- यह पता चलता है कि गुणवत्ता लगभग सभी विषयों के साथ अंतर करती है, जो चारों ओर सब कुछ पर एक फ्रेमवर्क लगाती है?

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

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

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

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

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

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

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

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

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

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

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

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

- एनालिटिक्स और डॉक्यूमेंटेशन के बारे में क्या?

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

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

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

डेवलपर्स कीट नहीं हैं और विशेष रूप से त्रुटियों के साथ कोड नहीं लिखते हैं।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- आप किस बारे में बात कर रहे हैं, आप सम्मेलन के मेहमान के रूप में किसे देखते हैं?

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

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

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

- क्या आपको लगता है कि इंडस्ट्री पूरी तरह से परिपक्व हो गई है ताकि न केवल परीक्षण के बारे में बात की जा सके, बल्कि गुणवत्ता की संस्कृति के बारे में भी बात की जा सके?

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

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

- सहमत! हम एक संस्कृति को पैदा करेंगे और मन को बदल देंगे।

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

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