टीम की जिम्मेदारी के रूप में गुणवत्ता। हमारा क्यूए अनुभव

अस्वीकरण: यह एक लेख का अनुवाद है। सभी अधिकार मूल लेख और मिरो कंपनी के लेखक के हैं।

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

पहले हमारी विकास प्रक्रिया के बारे में संक्षेप में। हमारे पास क्लाइंट साइड के लिए दैनिक रिलीज और सर्वर साइड के 3 से 5 साप्ताहिक रिलीज हैं। टीम में 10 कार्यात्मक स्कैम टीमों पर 60+ लोग हैं।

मैं इंटीग्रेशन टीम में काम कर रहा हूं। हमारे कार्य हैं:

• बाहरी उत्पादों में हमारी सेवा का एकीकरण
• हमारी सेवा में बाहरी उत्पादों का एकीकरण
  उदाहरण के लिए हमने जीरा को एकीकृत किया है। जीरा कार्ड - कार्यों का विज़ुअल प्रतिनिधित्व इसलिए यह उन कार्यों के साथ काम करने के लिए उपयोगी है जो जीरा को नहीं खोलते।
  
  

प्रयोग कैसे शुरू होता है

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

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

हम सोचने लगे हैं कि इस समस्या को कैसे हल किया जाए। हमें पता चलता है कि मूल कारण यह है कि परीक्षण चरण एक अड़चन है। मुझे इनमें से कुछ उदाहरण साझा करने दें।

केस 1: टास्क पिंग-पोंग

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

मैं पिछले कार्यों पर वापस जाता हूं। डेवलपर वर्तमान कार्यों से वापस लौटाए गए कार्य पर जाता है। फिक्सिंग के बाद डेवलपर रिटायर होने के लिए वापस मेरे पास काम करता है। मैंने फिर से दोष पाया और कार्य को फिर से वापस किया। यह लंबे समय तक जारी रह सकता है।

परिणामस्वरूप कार्य पर संचित समय कुछ समय में बढ़ रहा है और इसलिए बाजार के लिए समय जो एक उत्पाद कंपनी के रूप में हमारे लिए महत्वपूर्ण है। प्रयास बढ़ने के कुछ कारण हैं:

• टास्क लगातार टेस्ट इंजीनियर और डेवलपर के बीच घूम रहा है
• टेस्ट इंजीनियर या डेवलपर के इंतजार में टास्क खर्च करने का समय
• डेवलपर और टेस्ट इंजीनियर को अक्सर कार्य के बीच संदर्भ को स्विच करना पड़ता है जिससे समय और मानसिक ऊर्जा की अतिरिक्त कमी होती है।

केस 2: कार्यों की कतार बढ़ रही है

हमारी स्क्रम टीम में कुछ डेवलपर्स हैं। वे मुझे नियमित रूप से परीक्षण के लिए कार्य भेजते हैं। यह एक कार्य कतार बनाता है जिसे मैं प्राथमिकताओं के आधार पर आगे बढ़ाता हूं।

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

अचानक मैं बीमार हो गया। हमारी स्क्रैम टीम से उत्पादन तक नई सुविधाएँ वितरण पूरी तरह से रोक दिया गया था।
इस स्थिति में टीम को क्या करना चाहिए? किसी अन्य टीम के लिए टेस्ट इंजीनियर की मदद लेना संभव है। हालांकि एक अन्य टेस्ट इंजीनियर संदर्भ में नहीं है और उसे ज्ञान हस्तांतरण नहीं मिला है जो दोनों टीमों में गुणवत्ता और अनुसूची को नकारात्मक रूप से प्रभावित करेगा।

एक ही टीम में दोनों मामलों के परिणाम टेस्ट इंजीनियरों से बहुत अधिक हैं:

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

आइए टेस्ट इंजीनियर्स को जोड़ते हैं?

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

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

आइए विकास प्रक्रियाओं में सुधार करें

प्रयोग के उद्देश्य:

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

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

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

मेरी टीम ने अन्य टीमों के टेस्ट इंजीनियरों के साथ मिलकर नई प्रक्रिया बनाई थी। हमें इस नई प्रक्रिया के अनुसार डेढ़ साल के लिए काम किया गया था और इस समय के दौरान कुछ समस्याएँ ठीक हुईं और अब यह प्रक्रिया इस प्रकार दिखाई देती है:

1. कार्य विवरण पर प्रस्तुति
2. तकनीकी समाधान और परीक्षण परिदृश्य।
3. विकास और सत्यापन।
4. छोड़ें।

कार्य विवरण

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

तकनीकी समाधान

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

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

तकनीकी समाधान में कुछ ब्लॉकों का एक उदाहरण इस प्रकार है:

कार्य विवरण

क्या नई इकाइयाँ या दृष्टिकोण प्रणाली में शुरू हो रहे हैं?
यदि हाँ, तो ये स्पष्टीकरण के साथ वर्णित हैं कि वर्तमान दृष्टिकोणों के साथ कार्य को हल करना असंभव क्यों है।
एक क्लस्टर के भीतर सर्वर की बातचीत बदल रहे हैं? क्या नई क्लस्टर भूमिकाएँ शुरू हो रही हैं?

क्या डेटा मॉडल बदल रहा है?

सर्वर के लिए यह वस्तुओं और मॉडलों के बारे में है।
यदि डेटा मॉडल जटिल है, तो इसे ans UML आरेख या पाठ विवरण का प्रतिनिधित्व किया जा सकता है।

क्या क्लाइंट-सर्वर इंटरैक्शन बदल रहा है?

विवरण बदलता है। अगर यह एपीआई है तो क्या हम इसे प्रकाशित कर सकते हैं? अपवादों को संभालने के बारे में मत भूलना यानी सही कारण लॉग करें।

परीक्षण परिदृश्य

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

परीक्षण परिदृश्य बनाने और रखने के लिए हम हिपटेस्ट का उपयोग कर रहे हैं।

विकास और सत्यापन

डेवलपर टेक्निकल सॉल्यूशन और कॉर्नर मामलों और परीक्षण परिदृश्यों के आधार पर एक एप्लीकेशन कोड बनाता है। परीक्षण परिदृश्यों के विरुद्ध कोड की समीक्षा और सत्यापन सुविधा पास करना। मास्टर करने के लिए शाखा जोड़ता है।

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

किया कार्यक्षमता का विमोचन

यह एक अंतिम चरण है। यहां टीम को पूर्व और बाद के कार्यों को प्रदान करने की आवश्यकता हो सकती है। उदाहरण के लिए बीटा-उपयोगकर्ताओं के लिए नई कार्यक्षमता पर टॉगल करें।

प्रलेखन और उपकरण

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

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

प्रयोग के परिणाम

यह प्रयोग की शुरुआत के बाद से एक आधा साल है। प्रति सप्ताह बग राशि का एक ग्राफ है। सभी खोजे गए बगों की मात्रा को लाल रंग द्वारा दर्शाया गया है। निश्चित बग की मात्रा को हरे रंग से दर्शाया जाता है। पीली लाइन प्रयोग की एक शुरुआत है।

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

साथ ही कार्य पर बिताया गया औसत समय 2% घट गया: प्रयोग से 12 घंटे और 40 मिनट पहले। 12 घंटे 25 मिनट बाद। इसका मतलब है कि हम वेग बनाए रखने में कामयाब रहे।

नतीजतन एक टीम में क्यूए से अधिक कठिन निर्भरता नहीं है। अगर मैं बीमार हो जाऊंगा या छुट्टी पर जाऊंगा तो टीम वेग और गुणवत्ता में नुकसान के बिना विकास जारी रखेगी।

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

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

प्रयोग शुरू करने से पहले क्या ध्यान रखना चाहिए

यह एक जटिल और लंबा रास्ता है। इसे तुरंत लागू नहीं किया जा सका। इसके लिए तैयारी और धैर्य की आवश्यकता होती है। यह त्वरित जीत का वादा नहीं करता है।

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

शुरुआत में वेग हानि अपरिहार्य है। डेवलपर्स के लिए ज्ञान हस्तांतरण के लिए समय, लापता प्रलेखन बनाने और प्रक्रियाओं में बदलाव के लिए यह एक निवेश है।

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