सॉफ्टवेयर परीक्षण में दोष प्रबंधन प्रक्रिया (बग रिपोर्ट टेम्पलेट)

बग क्या है?

एक बग एक कोडिंग गलती का परिणाम / परिणाम है।

सॉफ्टवेयर परीक्षण में दोष

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

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

जब परीक्षक परीक्षण मामलों को निष्पादित करते हैं, तो वे ऐसे परीक्षा परिणामों में आ सकते हैं जो अपेक्षित परिणामों के विपरीत हैं। परीक्षण के परिणामों में इस भिन्नता को एक सॉफ्टवेयर दोष के रूप में जाना जाता है। इन दोषों या भिन्नताओं को विभिन्न संगठनों जैसे मुद्दों, समस्याओं, बगों या घटनाओं में अलग-अलग नामों से संदर्भित किया जाता है।

इस ट्यूटोरियल में, आप सीखेंगे-

• बग रिपोर्ट
• दोष प्रबंधन प्रक्रिया
• खोज
• वर्गीकरण
• संकल्प
• सत्यापन
• समापन
• रिपोर्टिंग
• महत्वपूर्ण दोष मेट्रिक्स

सॉफ्टवेयर परीक्षण में बग रिपोर्ट

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

बग को डेवलपर को रिपोर्ट करते समय, आपकी बग रिपोर्ट में निम्नलिखित जानकारी होनी चाहिए

• Defect_ID - दोष के लिए विशिष्ट पहचान संख्या।
• दोष विवरण - दोष का विस्तृत विवरण जिसमें मॉड्यूल के बारे में जानकारी शामिल थी जिसमें दोष पाया गया था।
• संस्करण - उस एप्लिकेशन का संस्करण जिसमें दोष पाया गया था।
• चरण - स्क्रीनशॉट के साथ विस्तृत कदम जिसके साथ डेवलपर दोषों को पुन: उत्पन्न कर सकता है।
• दिनांक उठाया - तिथि जब दोष उठाया है
• संदर्भ - आप में कहां दस्तावेजों की तरह संदर्भ प्रदान करें। आवश्यकताओं, डिजाइन, वास्तुकला या शायद दोष को समझने में मदद करने के लिए त्रुटि के स्क्रीनशॉट भी
• पता लगाया गया - दोष बढ़ाने वाले परीक्षक का नाम / आईडी
• स्थिति - दोष की स्थिति, इस पर बाद में
• द्वारा फिक्स्ड डेवलपर हैं जो यह तय का नाम / आईडी -
• दिनांक बंद - दोष बंद होने पर दिनांक
• गंभीरता जो अनुप्रयोग पर दोष के प्रभाव का वर्णन करती है
• प्राथमिकता जो दोष निर्धारण तात्कालिकता से संबंधित है। गंभीरता प्राथमिकता उच्च / मध्यम / निम्न प्रभाव की तात्कालिकता के आधार पर हो सकती है जिस पर क्रमशः दोष को ठीक किया जाना चाहिए

यदि वीडियो उपलब्ध नहीं है तो यहां क्लिक करें

साधन

एक नमूना दोष रिपोर्टिंग टेम्पलेट डाउनलोड करें

एक परीक्षण प्रबंधक के रूप में निम्नलिखित पर विचार करें

आपकी टीम ने गुरु99 बैंकिंग परियोजना का परीक्षण करते समय बग पाए।

एक हफ्ते के बाद डेवलपर ने जवाब दिया -

अगले हफ्ते में परीक्षक जवाब देता है

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

दोष प्रबंधन प्रक्रिया क्या है?

दोष प्रबंधन बग को पहचानने और ठीक करने के लिए एक व्यवस्थित प्रक्रिया है। एक दोष प्रबंधन चक्र में निम्नलिखित चरण शामिल हैं 1) दोष की खोज, 2) दोष वर्गीकरण 3) डेवलपर्स द्वारा दोष का निर्धारण 4) परीक्षकों द्वारा सत्यापन, 5) दोष बंद 6) परियोजना के अंत में दोष रिपोर्ट

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

खोज

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

उपरोक्त परिदृश्य में, परीक्षकों ने वेबसाइट गुरु 99 में 84 दोषों की खोज की।

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

ऐसे मामले में, एक परीक्षण प्रबंधक के रूप में, आप क्या करेंगे?
ए) परीक्षण टीम के साथ सहमत है कि इसका दोष है
बी) समस्या का दोष है या नहीं यह तय करने के लिए टेस्ट मैनेजर जज की भूमिका निभाता है
सी) विकास टीम के साथ सहमत हैं जो एक दोष नहीं है सही सुधार

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

वर्गीकरण

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

दोष आमतौर पर टेस्ट मैनेजर द्वारा वर्गीकृत किए जाते हैं -

आइए नीचे दिए गए दोष प्राथमिकता को खींचें और छोड़ें के रूप में एक छोटा व्यायाम करें

• नाजुक
• उच्च
• मध्यम
• कम

1) वेबसाइट का प्रदर्शन बहुत धीमा है
2) वेबसाइट का लॉगिन फ़ंक्शन ठीक से काम नहीं करता है
3) वेबसाइट का GUI मोबाइल उपकरणों पर सही ढंग से प्रदर्शित नहीं होता है
4) वेबसाइट उपयोगकर्ता लॉगिन सत्र को याद नहीं रख सकी
5) कुछ लिंक काम नहीं करते हैं

यहाँ सुझाए गए उत्तर दिए गए हैं

नहीं।	विवरण	वरीयता	व्याख्या
1	वेबसाइट का प्रदर्शन बहुत धीमा है	उच्च	प्रदर्शन बग उपयोगकर्ता के लिए भारी असुविधा पैदा कर सकता है।
२	वेबसाइट का लॉगिन फ़ंक्शन ठीक से काम नहीं करता है	नाजुक	लॉगिन बैंकिंग वेबसाइट का एक मुख्य कार्य है यदि यह सुविधा काम नहीं करती है, तो यह गंभीर बग है
३	वेबसाइट का GUI मोबाइल उपकरणों पर सही ढंग से प्रदर्शित नहीं होता है	मध्यम	दोष उस उपयोगकर्ता को प्रभावित करता है जो वेबसाइट देखने के लिए Smartphone का उपयोग करते हैं।
४	वेबसाइट उपयोगकर्ता लॉगिन सत्र को याद नहीं रख सकी	उच्च	यह एक गंभीर मुद्दा है क्योंकि उपयोगकर्ता लॉगिन करने में सक्षम होगा लेकिन आगे कोई लेनदेन करने में सक्षम नहीं होगा
५	कुछ लिंक काम नहीं करते	कम	यह विकास के लोगों के लिए एक आसान समाधान है और उपयोगकर्ता अभी भी इन लिंक के बिना साइट का उपयोग कर सकता है

दोष निवारण

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

दोष को ठीक करने के लिए आप निम्न चरणों का पालन कर सकते हैं।

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

सत्यापन

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

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

समापन

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

दोष रिपोर्टिंग

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

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

महत्वपूर्ण दोष मेट्रिक्स

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

परीक्षण निष्पादन की गुणवत्ता को कैसे मापें और मूल्यांकन करें?

यह एक ऐसा सवाल है, जिसे हर टेस्ट मैनेजर जानना चाहता है। 2 पैरामीटर हैं जो आप निम्नलिखित के रूप में विचार कर सकते हैं

उपरोक्त परिदृश्य में, आप विच्छेदन अस्वीकृति अनुपात (DRR) की गणना 20/84 = 0.238 (23.8%) कर सकते हैं।

एक अन्य उदाहरण, माना जाता है कि गुरु 99 बैंक की वेबसाइट में कुल 64 दोष हैं, लेकिन आपकी परीक्षण टीम केवल 44 दोषों का पता लगाती है अर्थात वे 20 दोषों से चूक गए हैं। इसलिए, आप दोष रिसाव अनुपात (DLR) की गणना 20/64 = 0.312 (31.2%) कर सकते हैं।

निष्कर्ष, परीक्षण निष्पादन की गुणवत्ता का मूल्यांकन दो मापदंडों का पालन करके किया जाता है

DRR और DLR का छोटा मूल्य है, परीक्षण निष्पादन की बेहतर गुणवत्ता है। अनुपात सीमा क्या है जो स्वीकार्य है ? इस रेंज को परियोजना लक्ष्य में परिभाषित और स्वीकार किया जा सकता है या आप इसी तरह की परियोजनाओं के मैट्रिक्स का उल्लेख कर सकते हैं।

इस परियोजना में, स्वीकार्य अनुपात का अनुशंसित मूल्य 5 ~ 10% है। इसका मतलब है कि परीक्षण निष्पादन की गुणवत्ता कम है। आपको इन अनुपातों को कम करने के लिए प्रतिवाद ढूंढना चाहिए जैसे कि

• सदस्य के परीक्षण कौशल में सुधार ।
• परीक्षण निष्पादन के लिए अधिक समय व्यतीत करें , विशेषकर परीक्षण निष्पादन परिणामों की समीक्षा के लिए।