मैंने विभिन्न कंपनियों के दर्जनों क्यूए इंजीनियरों के साथ बात की और उनमें से प्रत्येक ने इस तथ्य के बारे में बात की कि वे बग ट्रैकिंग के लिए विभिन्न प्रणालियों और उपकरणों का उपयोग करते हैं। हमने उनमें से कई को भी आजमाया, और हमने जो समाधान आया उसे साझा करने का फैसला किया।
परिचय
मैं भोज करूंगा। त्रुटियां दिखाई देती हैं और विकास प्रक्रिया के विभिन्न चरणों में पाई जाती हैं। इसलिए, आप बग को श्रेणियों में विभाजित कर सकते हैं, समय के आधार पर उनका पता लगाया गया था:
- कमियाँ । ये गलतियाँ हैं जो डेवलपर्स ने नई कार्यक्षमता को देखते हुए की हैं। ऐसी त्रुटियां अनुसंधान या टीमों के विकास स्टैंडों पर नई विशेषताओं के स्वीकृति परीक्षण के दौरान पाई जाती हैं।
- प्रतिगमन में कीड़े । ये ऐसे दोष हैं जो कोड एकीकरण के लिए स्टैंड पर मैनुअल रिग्रेशन टेस्ट या स्वचालित यूआई और एपीआई परीक्षण पाते हैं।
- एक बिक्री के साथ कीड़े । ये ऐसी समस्याएं हैं जो कर्मचारियों या ग्राहकों ने तकनीकी सहायता को पाया और उनसे संपर्क किया।
हम कहां से शुरू हुए, या जीरा
दो साल पहले, हमारे पास परीक्षकों की एक समर्पित टीम थी, जिसने सभी टीमों के कोड को एकीकृत करने के बाद मैन्युअल रूप से उत्पाद का परीक्षण किया था। इस बिंदु तक, डेवलपर स्टैंड पर डेवलपर्स द्वारा कोड का परीक्षण किया गया है। पाया गया कि परीक्षक जीरा में बैकलॉग में दर्ज किए गए थे। कीड़े को एक आम बैकलॉग में संग्रहीत किया गया और स्प्रिंट से अन्य कार्यों के साथ स्प्रिंट में स्थानांतरित कर दिया गया। प्रत्येक स्प्रिंट को दो या तीन बग मिलते हैं और उन्हें ठीक कर दिया जाता है, लेकिन अधिकांश बैकलॉग के निचले भाग में बने रहते हैं:
- बैकलॉग में कीड़े क्यों जमा होते हैं इसका एक कारण यह है कि वे उपयोगकर्ताओं के साथ हस्तक्षेप नहीं करते हैं। इस तरह के कीड़े की प्राथमिकता कम होती है और इसे ठीक नहीं किया जाएगा।
- इसके अलावा, अगर कंपनी के पास बग्स स्थापित करने के लिए स्पष्ट और समझने योग्य नियम नहीं हैं, तो परीक्षक एक ही समस्या को कई बार जोड़ सकते हैं क्योंकि वे इस सूची में पहले से ही जोड़े गए बग रिपोर्ट को नहीं ढूंढ सके।
- एक और कारण यह हो सकता है कि अनुभवहीन परीक्षक परियोजना में शामिल हैं। ऑपरेशन के दौरान पाए जाने वाले सभी बगों पर नज़र रखने के लिए शुरुआती परीक्षकों के लिए यह गलती है। अनुभवहीन परीक्षकों का मानना है कि परीक्षण का उद्देश्य उत्पाद की गुणवत्ता के बारे में जानकारी प्रदान करने और दोषों की उपस्थिति को रोकने के बजाय कीड़े की खोज करना है।
मैं एक सरल उदाहरण दूंगा। दिनांक इनपुट फ़ील्ड में रिपोर्ट बनाते समय, दिनांक डिफ़ॉल्ट रूप से प्रतिस्थापित किया जाता है। पॉपअप में तारीख बदलते समय, आप फिर से आज का चयन कर सकते हैं और तारीख इनपुट क्षेत्र को साफ कर दिया जाएगा।
मुझे संदेह है कि हमारे नेटवर्क के पूरे जीवन में, परीक्षकों के अलावा किसी ने भी इस त्रुटि को नहीं दोहराया है। इस तरह की त्रुटियां बग के अधिकांश हिस्से को तय करती हैं जो तय नहीं होती हैं।
इस दृष्टिकोण के साथ, जब सभी पाए गए बगों में प्रवेश किया जाता है, तो उनमें से कुछ की नकल की जाती है और इनमें से अधिकांश बगों की मरम्मत नहीं की जाती है।
- परीक्षकों को डिमोनेटाइज किया जाता है, क्योंकि वे जो त्रुटियां पाते हैं, वे डेवलपर्स द्वारा तय नहीं की जाती हैं। किसी को लगता है कि काम का कोई मतलब नहीं है।
- उत्पाद स्वामी के लिए बहुत सारे बग के साथ बैकलॉग का प्रबंधन करना कठिन है।
अलविदा जीरा, लंबे समय तक जीतेन
2018 के वसंत में, हमने जीरा को त्याग दिया और कैथेन चले गए। औजारों का परिवर्तन उन कारणों के कारण हुआ जिनके बारे में आंद्रेई आरिएफ़िएव ने लेख में लिखा था
" ट्रोडो
और जीरा के एक समूह के बजाय डोडो पिज्जा काइटेन
का उपयोग क्यों करना शुरू किया"। कैथेन में जाने के बाद, बग के साथ काम करने का हमारा दृष्टिकोण नहीं बदला है:
- कमांड बोर्ड में खामियों को दर्ज किया गया था और डेवलपर्स ने स्वतंत्र रूप से उनकी मरम्मत करने का फैसला किया था।
- प्रतिगमन में पाए जाने वाले कीड़े (यह परीक्षकों की एक समर्पित टीम द्वारा किया गया था) को रिलीज शाखा में मरम्मत की गई थी और सभी समस्याओं को ठीक करने तक कोड जारी नहीं किया था। हमने फैसला किया कि स्लैक में टेस्टर्स चैनल में इन समस्याओं के बारे में जानकारी रखना और एकत्र करना अधिक तर्कसंगत होगा। परीक्षकों ने एक संदेश लिखा जिसमें एक किंवदंती, लॉग के साथ बग की एक सूची और डेवलपर्स के नाम शामिल थे जिन्होंने काम करने के लिए कार्य लिया। इमोजी की मदद से, उन्होंने स्थिति बदल दी, और ट्रेडों में उन्होंने चर्चा की, स्क्रीनशॉट लागू किए, सिंक्रनाइज़ किए गए। यह प्रारूप अनुकूल परीक्षकों। कुछ डेवलपर्स को यह तरीका पसंद नहीं आया, क्योंकि चैट में समानांतर में एक और पत्राचार था और यह संदेश ऊपर गया और दिखाई नहीं दिया। हमने इसे ठीक किया, लेकिन इसने जीवन को सरल नहीं बनाया।
- ठेस पर पाए जाने वाले कीड़े बैकलॉग में दर्ज किए गए थे, उत्पाद मालिक ने प्राथमिकता दी और उन लोगों को चुना जो हम मरम्मत करेंगे।
प्रयोग समय या नहीं
हमने प्रारूपों के साथ प्रयोग करने का निर्णय लिया और कैथेन में एक अलग बोर्ड बनाया, जिस पर हमने बग बनाए और स्थिति बदली। हमने कम समय बिताने के लिए बग रिपोर्ट की स्थापना को सरल बनाया। Kaiten में एक कार्ड जोड़ते समय, परीक्षकों ने डेवलपर्स को चिह्नित किया। इस बारे में उनके मेल पर एक अधिसूचना भेजी गई। हमने इस बोर्ड को एक मॉनिटर पर रखा है जो हमारे कार्यस्थल के पास गलियारे में लटका हुआ है, ताकि डेवलपर्स प्रगति देख सकें और परीक्षण प्रक्रिया पारदर्शी हो जाए। इस अभ्यास ने भी जड़ नहीं ली, क्योंकि मुख्य संचार चैनल स्लैक है। हमारे डेवलपर्स अक्सर मेल की जांच नहीं करते हैं। इसलिए, इस समाधान ने जल्दी से काम करना बंद कर दिया और हम स्लैक में लौट आए।
चींटियों को वापस लाओ
कैटन में एक असफल बोर्ड प्रयोग के बाद, कुछ डेवलपर्स अभी भी स्लैक में संदेश प्रारूप के खिलाफ थे। और हमने यह सोचना शुरू किया कि कैसे सुस्त में बग को ट्रैक करें और डेवलपर्स को रोकने वाली समस्याओं को हल करें। खोजों के परिणामस्वरूप, मुझे स्लैक, वर्कस्ट के लिए एक आवेदन मिला, जो मैसेंजर में राइटर्स के साथ काम को व्यवस्थित करने में मदद करता है। हमने सोचा कि यह एप्लिकेशन आपको अधिक लचीले ढंग से बग के साथ काम करने की प्रक्रिया का प्रबंधन करने की अनुमति देगा। इस एप्लिकेशन के अपने फायदे थे: एक बटन के क्लिक पर डेवलपर्स के लिए स्थिति और असाइनमेंट में परिवर्तन, पूर्ण किए गए कार्य छिपे हुए थे और संदेश विशाल आकार तक नहीं बढ़ा था।
तो हल की गई समस्याओं को टोडो आवेदन में देखा गया और "चींटियों" को वापस करने का अनुरोध किया गया। वर्कस्ट एप्लिकेशन के परीक्षण की अवधि समाप्त होने के बाद, हमने इसे छोड़ने का फैसला किया। क्योंकि इस एप्लिकेशन का उपयोग करते हुए, हम उसी चीज के लिए आए थे जब हमने जीरा का उपयोग किया था। कुछ कीड़े थे जो इस सूची पर फिर से पाने के लिए भटकते थे। और प्रत्येक पुनरावृत्ति के साथ, उनमें से अधिक थे। शायद यह इस विस्तार के साथ काम करने की प्रक्रिया को अंतिम रूप देने के लायक था, इसे खरीदें और इसका उपयोग करें, लेकिन हमने नहीं किया।
अब कीड़े से निपटने का हमारा सही तरीका है
2018 के अंत में - 2019 की शुरुआत में, हमारी कंपनी में कई बदलाव हुए जिन्होंने बग के साथ काम करने की प्रक्रिया को प्रभावित किया।
सबसे पहले, हमारे पास परीक्षकों की एक समर्पित टीम नहीं थी। सभी परीक्षकों ने परीक्षण टीमों की क्षमता को मजबूत करने के लिए, विकास टीमों में फैलाया। इसके लिए धन्यवाद, हमने कमांड कोड के एकीकरण से पहले, पहले त्रुटियों को ढूंढना शुरू कर दिया था।
दूसरे, हमने ऑटोमैटिक के पक्ष में मैनुअल रिग्रेशन टेस्टिंग को छोड़ दिया।
तीसरा, हमने "शून्य बग नीति" को अपनाया। "
#Zerobugpolicy या हम कैसे कीड़े को ठीक करते हैं "
लेख में bevzuk विवरण
बताते हैं कि हम उन कीड़े का चयन कैसे करते हैं जिन्हें हम ठीक करते हैं।
आज बग के साथ काम करने की प्रक्रिया इस प्रकार है:
- कमियाँ । परीक्षक विश्लेषकों या उत्पाद प्रबंधकों को समस्या की रिपोर्ट करते हैं। वे चलते हैं, दिखाते हैं, पुन: पेश करते हैं, बताते हैं कि यह ग्राहकों को कैसे प्रभावित करेगा और यह तय करेगा कि इसे रिलीज से पहले मरम्मत करने की आवश्यकता है या बाद में मरम्मत की जा सकती है, या शायद यह बिल्कुल भी मरम्मत के लायक नहीं है।
- प्रतिगमन में कीड़े जो ऑटो-परीक्षण में पाए जाते हैं उनकी मरम्मत टीम द्वारा की जाती है जो सिस्टम के इस हिस्से को छूते हैं और हम इस कोड को तब तक जारी नहीं करेंगे जब तक हम समस्या को हल नहीं करते। परीक्षक इन खामियों को स्लैक में रिलीज़ चैनल पर एक मनमाना प्रारूप में तय करते हैं।
- एक बिक्री के साथ कीड़े । ऐसे कीड़े सीधे कार्य स्वामियों के पास जाते हैं। विश्लेषकों ने बग की प्राथमिकता मैट्रिक्स पर त्रुटियों को चलाया और बैकलॉग में जोड़ दिया या इसे अपने दम पर ठीक कर दिया, इस मुद्दे पर हिट के आंकड़े जमा किए।
परिणाम
संक्षेप में, हमने मूल रूप से बग ट्रैकिंग सिस्टम को छोड़ दिया । बग के साथ काम करने के लिए इस दृष्टिकोण का उपयोग करते हुए, हमने कई दर्द हल किए:
- परीक्षक परेशान नहीं होते हैं क्योंकि बग ट्रैकिंग में उन्हें खोजने और ट्रिगर करने वाली त्रुटियां तय नहीं होती हैं।
- परीक्षक किसी संस्था पर समय नहीं देते हैं और बगों का पूरा विवरण जो कोई भी नहीं पढ़ेगा।
- पीओ ऐसे बैकलॉग का प्रबंधन करना आसान है जिसमें कोई डेड लोड नहीं है।
मैं यह नहीं कहना चाहता कि ट्रैकिंग बग बेकार है। हम जो कीड़े काम में लेते हैं, उन्हें किसी भी अन्य कार्यों की तरह ट्रैक किया जाता है। लेकिन बग ट्रैकिंग सिस्टम एक आवश्यक परीक्षण विशेषता नहीं है। इसे केवल उपयोग करने की आवश्यकता नहीं है क्योंकि अधिकांश कंपनियां इसका उपयोग करती हैं और इसलिए उद्योग में प्रथागत है। आपको "अपने सिर के साथ सोचने" और अपनी प्रक्रियाओं और जरूरतों के लिए उपकरणों पर प्रयास करने की आवश्यकता है। बग ट्रैकिंग सिस्टम के बिना काम करना अब हमारे लिए आदर्श है। इस तरह के काम के आधे साल के लिए, हमने उस पर लौटने और फिर से सभी कीड़े होने के बारे में कभी नहीं सोचा।
और आपकी कंपनी में व्यवस्थित बग के साथ काम करने की प्रक्रिया कैसी है?