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

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

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

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

आपको दोष प्रबंधन प्रक्रिया की आवश्यकता क्यों है?

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

एक सप्ताह बाद, डेवलपर इस मुद्दे के बारे में एक अलग समझ के साथ जवाब देता है।

अगले सप्ताह, परीक्षक फिर से जवाब देता है, जिससे और भी अधिक भ्रम की स्थिति पैदा हो जाती है।

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

चरण 1) खोज

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

उदाहरण के तौर पर, परीक्षकों ने 84 दोषों का पता लगाया। Guru99 बैंक की वेबसाइट।

हालांकि, परीक्षक और डेवलपर हमेशा सहमत नहीं होते। निम्नलिखित मामले को देखें, जिसमें परीक्षण टीम कुछ समस्याओं की पहचान करती है। Guru99 बैंक की वेबसाइट पर इसकी रिपोर्ट की गई है, लेकिन विकास टीम इस बात पर विवाद कर रही है कि क्या ये खामियां हैं:

ऐसे में, एक टेस्ट मैनेजर के रूप में आपको क्या करना चाहिए?

ए) परीक्षण टीम से सहमत हों कि यह एक दोष है।
बी) न्यायाधीश की भूमिका निभाएं और तय करें कि समस्या कोई दोष है या नहीं।
सी) विकास टीम से सहमत हों कि यह कोई दोष नहीं है।

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

चरण 2) वर्गीकरण

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

दोषों को आमतौर पर चार प्राथमिकता स्तरों में वर्गीकृत किया जाता है: गंभीर, उच्च, मध्यम और निम्ननिम्नलिखित प्रत्येक दोष को सही प्राथमिकता देने का प्रयास करें:

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

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

नहीं.	विवरण	प्राथमिकता	व्याख्या
1	वेबसाइट का प्रदर्शन बहुत धीमा है	हाई	प्रदर्शन संबंधी समस्याओं के कारण अंतिम उपयोगकर्ताओं को भारी असुविधा होती है।
2	लॉगिन फ़ंक्शन ठीक से काम नहीं कर रहा है	आलोचनात्मक	बैंकिंग वेबसाइट का एक मुख्य कार्य लॉगिन करना है। यदि यह विफल हो जाता है, तो उपयोगकर्ता की पूरी प्रक्रिया बाधित हो जाती है।
3	मोबाइल उपकरणों पर ग्राफिकल यूजर इंटरफेस (GUI) सही ढंग से प्रदर्शित नहीं होता है।	मध्यम	यह खामी उन उपयोगकर्ताओं को प्रभावित करती है जो स्मार्टफोन पर वेबसाइट देखते हैं।
4	वेबसाइट उपयोगकर्ता लॉगिन सत्र को याद नहीं रख सकती।	हाई	उपयोगकर्ता लॉग इन तो कर सकते हैं, लेकिन आगे कोई लेन-देन नहीं कर सकते।
5	कुछ लिंक काम नहीं कर रहे हैं	निम्न	डेवलपर्स के लिए यह एक आसान समाधान है, और उपयोगकर्ता अभी भी साइट के बाकी हिस्सों तक पहुंच सकते हैं।

चरण 3) दोष समाधान

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

किसी खराबी को ठीक करने के लिए आप इन चरणों का पालन कर सकते हैं:

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

चरण 4) सत्यापन

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

उदाहरण के लिए, जब विकास टीम यह रिपोर्ट करती है कि 61 दोषों को ठीक कर दिया गया है, तो परीक्षण टीम यह पुष्टि करने के लिए प्रत्येक दोष का पुनः परीक्षण करती है कि क्या सुधार उन्हीं परिस्थितियों में सही ढंग से काम करते हैं जिनके कारण मूल विफलता हुई थी।

चरण 5) समापन

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

चरण 6) दोष रिपोर्टिंग

दोष रिपोर्टिंग सॉफ्टवेयर टेस्टिंग में, टेस्ट मैनेजर्स द्वारा दोष की स्थिति तैयार करने और उसे प्रबंधन टीम के साथ साझा करने की प्रक्रिया है। प्रबंधन टीम रिपोर्ट की समीक्षा करती है और आवश्यकता पड़ने पर प्रतिक्रिया या अतिरिक्त सहायता प्रदान करती है। दोष रिपोर्टिंग से संचार में सुधार होता है। tracराजा, और दोषों के बारे में दृश्यता।

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

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

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

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

यह एक महत्वपूर्ण प्रश्न है हर किसी के लिए टेस्ट मैनेजर इसका उत्तर देना चाहता है। आमतौर पर दो प्रमुख मापदंडों का उपयोग किया जाता है:

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

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

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

DRR और DLR मान जितने कम होंगे, परीक्षण निष्पादन की गुणवत्ता उतनी ही बेहतर होगी। स्वीकार्य सीमा आमतौर पर परियोजना लक्ष्यों द्वारा परिभाषित की जाती है या समान परियोजनाओं के आधार पर निर्धारित की जाती है। इस उदाहरण में, अनुशंसित स्वीकार्य सीमा यह है: 5% 10% करने के लिएवर्तमान निष्पादन इस सीमा से बाहर है, जो यह संकेत देता है कि निम्नलिखित उपायों के माध्यम से परीक्षण की गुणवत्ता में सुधार किया जाना चाहिए:

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

प्रभावी दोष प्रबंधन के लिए सर्वोत्तम पद्धतियाँ

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

यहां कुछ बेहतरीन तरीके दिए गए हैं जिन्हें शुरुआती और मध्यवर्ती स्तर के परीक्षकों को तुरंत अपनाना चाहिए:

1. दोष टेम्पलेट को मानकीकृत करें: डिफेक्ट आईडी जैसे फ़ील्ड वाले एक निश्चित डिफेक्ट रिपोर्ट टेम्पलेट का उपयोग करें, Descriptआयन, समस्या को दोहराने के चरण, गंभीरता, प्राथमिकता, वातावरण और संलग्नक। एकरूपता परीक्षकों और डेवलपर्स के बीच बार-बार होने वाली बातचीत को कम करती है।
2. कार्य सौंपने से पहले प्राथमिकता निर्धारित करें: किसी भी खराबी को डेवलपर को भेजने से पहले, उसे उसकी गंभीरता और प्राथमिकता के आधार पर वर्गीकृत करें। इससे यह सुनिश्चित होता है कि गंभीर समस्याएं छोटी-मोटी समस्याओं के पीछे न दब जाएं।
3. रिपोर्ट करने से पहले पुनरुत्पादन करें: शिकायत दर्ज करने से पहले, कम से कम दो बार स्वच्छ वातावरण में दोष की पुनरावृति करें। पुनरावृति योग्य दोषों को जल्दी ठीक किया जा सकता है और अस्वीकृति अनुपात को कम किया जा सकता है।
4. किसी दोष को अपनाएं tracकिंग टूल: जैसे टूल का उपयोग करें जिरा, Bugzillaया, एक प्रकार का कीड़ा केंद्रीकृत करना tracराजा, इतिहास और रिपोर्टिंग।
5. प्राथमिक उपचार बैठकें आयोजित करें: QA, डेवलपमेंट और प्रोडक्ट टीमों के बीच प्राथमिकताओं को संरेखित करने के लिए संक्षिप्त, केंद्रित दोष निवारण बैठकें आयोजित करें।
6. रिसाव और अस्वीकृति को मापें: Tracप्रत्येक स्प्रिंट या चक्र में k DLR और DRR की जाँच करें। बढ़ती लीकेज दर इस बात का प्रारंभिक संकेत है कि परीक्षण कवरेज अपूर्ण है।
7. मूल कारण का विश्लेषण करें: बार-बार होने वाली या अत्यधिक गंभीर समस्याओं के लिए, मूल कारण विश्लेषण करें ताकि भविष्य के रिलीज में उसी प्रकार की समस्या दोबारा न आए।
8. रिपोर्टिंग के माध्यम से प्रक्रिया को पूरा करें: हितधारकों के साथ साप्ताहिक दोष डैशबोर्ड साझा करें ताकि समस्याएं स्पष्ट रूप से दिखाई दें और उन पर कार्रवाई की जा सके।

इन प्रक्रियाओं को लगातार लागू करने से दोष जीवनचक्र स्थिर होता है और प्रत्येक रिलीज की समग्र गुणवत्ता में सुधार होता है।

संसाधन:

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

अक्सर पूछे जाने वाले प्रश्न