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

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

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

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

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

चरण 1) खोज

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

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

खोज

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

ऐसी स्थिति में, एक टेस्ट मैनेजर के रूप में आप क्या करेंगे?

A) परीक्षण टीम से सहमत हैं कि यह एक दोष है

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

सी) विकास टीम से सहमत हैं कि यह कोई दोष नहीं है

सही बात
गलत

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

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

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

वर्गीकरण

दोषों को आमतौर पर परीक्षण प्रबंधक द्वारा वर्गीकृत किया जाता है –

आइये एक छोटा सा अभ्यास करें जैसा कि नीचे दिया गया है

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

यहां अनुशंसित उत्तर दिए गए हैं

नहीं. विवरण प्राथमिकता व्याख्या

1

वेबसाइट का प्रदर्शन बहुत धीमा है

हाई

प्रदर्शन संबंधी बग के कारण उपयोगकर्ता को भारी असुविधा हो सकती है।

2

वेबसाइट का लॉगिन फ़ंक्शन ठीक से काम नहीं करता

आलोचनात्मक

लॉगिन बैंकिंग वेबसाइट का एक मुख्य कार्य है, यदि यह सुविधा काम नहीं करती है, तो यह गंभीर बग है

3

वेबसाइट का GUI मोबाइल डिवाइस पर सही ढंग से प्रदर्शित नहीं होता

मध्यम

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

4

वेबसाइट उपयोगकर्ता के लॉगिन सत्र को याद नहीं रख सकी

हाई

यह एक गंभीर मुद्दा है क्योंकि उपयोगकर्ता लॉगइन तो कर सकेगा लेकिन आगे कोई लेनदेन नहीं कर सकेगा

5

कुछ लिंक काम नहीं करते

निम्न

यह विकास के लोगों के लिए एक आसान समाधान है और उपयोगकर्ता इन लिंक के बिना भी साइट तक पहुंच सकता है

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

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

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

दोष समाधान

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

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

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

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

चरण 5) समापन

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

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

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

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

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

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

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

एक सप्ताह के बाद डेवलपर जवाब देता है –

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

अगले सप्ताह परीक्षक जवाब देगा

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

बग कोडिंग त्रुटि का परिणाम/परिणाम है।

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

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

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

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

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

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

संसाधन:

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