त्रुटि रिपोर्टिंग में सुधार के लिए अस्वीकृत दोष दर का उपयोग करना

महान शुक्रवार सब लोग, दोस्तों! जून के अंत में, हम क्यूए विशेषज्ञ पाठ्यक्रम में एक नया समूह शुरू कर रहे हैं, जो आज के प्रकाशन का फोकस होगा।



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

अस्वीकृत त्रुटियों की तीन श्रेणियां हैं:

• इररेप्रोडयूसीबल त्रुटियां;
• गलत त्रुटियां
• डुप्लिकेट त्रुटियां।

चलिए गलतियों की शुरुआत खुद से करते हैं।

अपरिवर्तनीय त्रुटियां

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

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

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

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

इन दोनों प्रकार की त्रुटियों को आमतौर पर त्रुटि रिपोर्टिंग सिस्टम में "अस्वीकृत - पुन: प्रस्तुत नहीं किया जा सकता" के रूप में चिह्नित किया जाता है।

गलत त्रुटियां

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

इस तरह की त्रुटियों को आमतौर पर त्रुटि रिपोर्टिंग सिस्टम में "अस्वीकृत - त्रुटि नहीं" या "अस्वीकृत - वास्तुकला द्वारा" के रूप में चिह्नित किया जाता है (अर्थात, व्यवहार वास्तुकला के अनुरूप है)।

डुप्लिकेट त्रुटियां

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

इन त्रुटियों को आमतौर पर त्रुटि रिपोर्टिंग सिस्टम में "अस्वीकृत - डुप्लिकेट / दोहराने" के रूप में चिह्नित किया जाता है।

कैसे अस्वीकृत त्रुटियां एक टीम को प्रभावित करती हैं

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

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

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

बदले में, अगर यह पता चला कि मुझे मिली त्रुटि अस्वीकार कर दी गई है, तो मुझे नाराजगी है, क्योंकि मुझे एक लेपर्सन माना जाता था। एक ओर, इसका मतलब है कि मैं मिली त्रुटियों का बचाव करूंगा। जब मेरी रिपोर्ट खारिज कर दी जाती है, तो मैं इस प्रकार आगे बढ़ता हूं:

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

दूसरी ओर, त्रुटि अस्वीकृति की एक निश्चित संभावना मुझे सतर्क करती है। अगर मुझे पूरी तरह से यकीन नहीं है कि मुझे एक बग मिला है, तो मैं रिपोर्ट करने से पहले कुछ और समय बिताऊंगा। मैं अक्सर किसी सहकर्मी से पूछता हूं कि क्या मैं आवश्यकताओं की सही व्याख्या करता हूं, या मैं जांचता हूं कि क्या त्रुटि किसी और के सिस्टम पर पुन: प्रस्तुत की गई है।

अस्वीकृत त्रुटियों की पूर्ण अनुपस्थिति के खिलाफ राय

परीक्षण टीम को आरडीआर के स्तर को कम करने के लिए निगरानी और प्रयास करना चाहिए। एकमात्र सवाल यह है कि आरडीआर को क्या अच्छा माना जाना चाहिए?

पहली नज़र में, ऐसा लगता है कि 0% इष्टतम परिणाम है, लेकिन मैं इससे दृढ़ता से असहमत हूं। मेरा मानना ​​है कि जब आरडीआर को कुछ स्वस्थ स्तर पर रखा जाता है, तो यह सामान्य है, क्योंकि यदि यह शून्य के करीब है, तो परीक्षण टीम स्पष्ट रूप से अत्यधिक गंभीर आरडीआर की तुलना में कम गंभीर समस्याओं से ग्रस्त नहीं है।

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

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

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

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

हमें ऐसे परीक्षकों की आवश्यकता है जो समय-समय पर गलतियाँ करने से नहीं डरते। इसका मतलब है कि संतुलन की जरूरत है, इसलिए कुछ छोटे आरडीआर को स्वीकार्य माना जाता है।

इष्टतम अस्वीकार किए गए दोष दर का पता लगाना

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

मुझे नहीं लगता कि मेरे भीतर की भावना के अलावा इस अर्थ का कोई औचित्य है। यह निश्चित रूप से वैज्ञानिक नहीं है। मैं ऐसी टीम के साथ बहस नहीं करूंगा जिसका उद्देश्य 10 या 20 प्रतिशत है, लेकिन मुझे लगता है कि 30 प्रतिशत के साथ या 5 प्रतिशत का लक्ष्य निर्धारित करना पहले से ही एक समस्या है।

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

परंपरा से, हम आपकी टिप्पणियों की प्रतीक्षा कर रहे हैं और आपको एक मुफ्त वेबिनार में आमंत्रित करते हैं, जो 14 जून को आयोजित किया जाएगा। जल्द मिलते हैं!