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

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

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

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

प्रयोग कैसे शुरू हुआ?

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

छुट्टी पर परीक्षक का प्रस्थान एक और कहानी है। उसे उन परीक्षकों में से एक को खोजने की जरूरत है जो अपने कार्यों के अलावा अपने कार्यों को लेने के लिए, सहमत होने के लिए, कार्यों में विसर्जित होने के लिए तैयार है। एक ही समय में, दो परीक्षक छुट्टी पर जाते हैं एक अभेद्य विलासिता है।

हम इस समस्या के समाधान के बारे में सोचने लगे, और महसूस किया कि वास्तविक समस्या यह थी कि विकास प्रक्रियाओं की संकीर्ण गर्दन परीक्षण कर रही थी। मैं आपको कई कहानियों का एक उदाहरण दिखाऊंगा।

पहली कहानी: अंतहीन कार्य रोलबैक

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

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



नतीजतन, कार्य पर काम का कुल समय कई गुना बढ़ जाता है, इसके बाद बाजार में समय की वृद्धि होती है, और यह एक खाद्य कंपनी के रूप में हमारे लिए महत्वपूर्ण है। कार्य में लगने वाले समय को बढ़ाने के कई कारण हैं:

1. विकास और परीक्षण के बीच कार्य लगातार बदल रहा है।
2. कार्य एक परीक्षक या डेवलपर के लिए बेकार है।
3. डेवलपर और परीक्षक को नियमित रूप से कार्यों के बीच स्विच करना पड़ता है, जिसके लिए अतिरिक्त समय और ऊर्जा की आवश्यकता होती है।

दूसरी कहानी: कार्यों की बढ़ती रेखा

हमारी स्कोर टीम में कई डेवलपर्स हैं। वे नियमित रूप से परीक्षण के लिए अपने कार्य मुझे सौंप देते हैं। कार्यों की एक कतार, जिसके लिए मैं प्राथमिकता के आधार पर कार्य करता हूं।

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

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

दोनों कहानियों से निष्कर्ष समान है - टीमें परीक्षक पर बहुत अधिक निर्भर करती हैं:

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

आइए परीक्षकों के कर्मचारियों को बढ़ाएं?

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

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

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

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

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

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

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

टीम के साथ और अन्य टीमों के परीक्षकों के साथ, हमने एक नई कार्य योजना विकसित की। आधे साल तक, जैसा कि टीम इस पर काम करती है, हमने रास्ते में आने वाली कठिनाइयों और समस्याओं को ध्यान में रखा, और आज यह इस तरह दिखता है:

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

समस्या का बयान

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

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

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

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

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

कार्य विवरण

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

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

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

क्या क्लाइंट और सर्वर के बीच की बातचीत बदल रही है?

परिवर्तनों का विवरण यदि यह एक एपीआई है, तो क्या यह बाहरी उपयोगकर्ताओं को दिया जा सकता है? त्रुटि से निपटने के बारे में मत भूलना - अर्थात् सही कारण बताएं।

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

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

स्क्रिप्ट के संकलन और भंडारण के लिए हम हिपटेस्ट का उपयोग करते हैं।

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

प्रयोग शुरू करने से पहले याद रखने योग्य बातें

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

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

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

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