मेन्यू

उदाहरणों और अंतर के साथ परीक्षण में दोष की गंभीरता और प्राथमिकता

defect severity priority testing with examples

समस्याओं को खत्म करने के लिए हमारे साधन का प्रयास करें

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

हम विभिन्न बाल्टियों में दोषों को वर्गीकृत करने और दोषपूर्ण जीवन चक्र में उनकी प्रासंगिकता के बारे में विस्तार से बताएंगे। हम उदाहरणों के जीवंत सेट के साथ वर्गीकरण की महत्वपूर्ण भूमिका को भी कवर करेंगे।

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

दोष गंभीरता और प्राथमिकता

आप क्या सीखेंगे:

दोष ट्रैकिंग अवलोकन

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

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

प्रभावी दोष ट्रैकिंग और रिज़ॉल्यूशन के लिए आधार बनाने वाले दो मुख्य पैरामीटर हैं:

सबसे अच्छा मुफ्त संगीत डाउनलोडर क्या है?
  • परीक्षण में दोष प्राथमिकता
  • परीक्षण में दोष गंभीरता

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

आइए अगले भाग में दो मापदंडों की सैद्धांतिक परिभाषाओं को संक्षेप में समझते हैं।

दोष गंभीरता और प्राथमिकता क्या है?

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

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

ये कौन परिभाषित करता है?

क्यूए दोष की जटिलता और आलोचना के आधार पर उपयुक्त गंभीरता के तहत दोष को वर्गीकृत करता है।

परियोजना प्रबंधकों, व्यवसाय विश्लेषकों, उत्पाद स्वामी सहित कोई भी व्यावसायिक हितधारक दोषों की प्राथमिकता को परिभाषित करते हैं।

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

स्थिरता और प्राथमिकता

इन स्तरों को कैसे चुनें?

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

गंभीरता और प्राथमिकता के बीच अंतर

प्राथमिकता शेड्यूलिंग से जुड़ी है, और 'गंभीरता' मानकों से जुड़ी है।

'प्राथमिकता' का अर्थ है कि किसी चीज़ पर ध्यान दिया जाना चाहिए या पहले ध्यान दिया जाना चाहिए; महत्व (या तात्कालिकता) के आदेश द्वारा स्थापित पूर्वता।

'गंभीरता' गंभीर होने की स्थिति या गुणवत्ता है; गंभीर का अर्थ है कठोर मानकों या उच्च सिद्धांतों का पालन करना और अक्सर कठोरता का सुझाव देना; गंभीर द्वारा चिह्नित किया जाता है या कठोर मानकों या उच्च सिद्धांतों के सख्त पालन की आवश्यकता होती है, उदाहरण के लिए, व्यवहार का एक गंभीर कोड।

बग ट्रैकिंग में प्राथमिकता और गंभीरता शब्द आते हैं।

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

फ़िक्सेस प्रोजेक्ट 'प्राथमिकताओं' और बग्स की 'गंभीरता' पर आधारित हैं।

समस्या की The गंभीरता 'को ग्राहक के जोखिम मूल्यांकन के अनुसार परिभाषित किया गया है और उनके चयनित ट्रैकिंग टूल में दर्ज किया गया है।

बग्गी सॉफ़्टवेयर शेड्यूल को 'गंभीर रूप से प्रभावित' कर सकता है, जो बदले में, 'प्राथमिकताओं' के पुनर्मूल्यांकन और पुनर्जागरण का कारण बन सकता है।

प्राथमिकता क्या है?

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

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

मोटे तौर पर, दोषों की प्राथमिकता को निम्नानुसार वर्गीकृत किया जा सकता है:

प्राथमिकता # 1) तत्काल / महत्वपूर्ण (P1)

इसे 24 घंटे के भीतर तुरंत ठीक करना होगा। यह आमतौर पर ऐसे मामलों में होता है जब एक संपूर्ण कार्यक्षमता अवरुद्ध हो जाती है और कोई भी परीक्षण इसके परिणामस्वरूप आगे नहीं बढ़ सकता है। या कुछ अन्य मामलों में यदि महत्वपूर्ण मेमोरी लीक हैं, तो आमतौर पर दोष को प्राथमिकता -1 के रूप में वर्गीकृत किया जाता है, जिसका अर्थ है कि वर्तमान स्थिति में कार्यक्रम / सुविधा अनुपयोगी है।

कोई भी दोष जिसे तत्काल ध्यान देने की आवश्यकता है जो परीक्षण प्रक्रिया को प्रभावित करता है उसे तत्काल श्रेणी के तहत वर्गीकृत किया जाएगा

सब गंभीर गंभीरता दोष इस श्रेणी में आते हैं (जब तक कि व्यवसाय / हितधारकों द्वारा फिर से प्राथमिकता नहीं दी जाती)

प्राथमिकता # 2) उच्च (P2)

एक बार महत्वपूर्ण दोष तय हो जाने के बाद, यह प्राथमिकता रखने वाला दोष अगला उम्मीदवार होता है जिसे 'बाहर निकलने' के मानदंडों से मेल खाने के लिए किसी भी परीक्षण गतिविधि के लिए तय किया जाना होता है। आम तौर पर जब कोई फीचर प्रयोग करने योग्य नहीं होता है जैसा कि प्रोग्राम दोष के कारण होना चाहिए, या उस नए कोड को लिखना होता है या कभी-कभी इसलिए भी क्योंकि कुछ पर्यावरणीय समस्या को कोड के माध्यम से हैंडल करना पड़ता है, एक दोष प्राथमिकता 2 के लिए योग्य हो सकता है ।

यह दोष या मुद्दा है जिसे रिलीज होने से पहले हल किया जाना चाहिए। एक बार क्रिटिकल मुद्दों को हल करने के बाद इन दोषों को हल किया जाना चाहिए।

सब प्रमुख तीव्रता दोष इस श्रेणी में आते हैं।

प्राथमिकता # 3) मध्यम (P3)

इस प्राथमिकता के साथ एक दोष निश्चित होना चाहिए क्योंकि यह कार्यक्षमता के मुद्दों से भी निपट सकता है जो अपेक्षा के अनुसार नहीं हैं। कभी-कभी यहां तक ​​कि कॉस्मेटिक त्रुटियों जैसे कि विफलता के दौरान सही त्रुटि संदेश की अपेक्षा करना प्राथमिकता 3 दोष हो सकता है।

सभी गंभीर कीड़े ठीक होने के बाद इस दोष को हल किया जाना चाहिए।

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

सब नाबालिग तीव्रता दोष इस श्रेणी में आते हैं।

प्राथमिकता # 4) निम्न (P4)

कम प्राथमिकता वाला दोष यह दर्शाता है कि निश्चित रूप से एक मुद्दा है, लेकिन यह 'निकास' मानदंड से मेल नहीं खाता है। हालांकि, यह GA होने से पहले तय किया जाना चाहिए। आमतौर पर, पहले से चर्चा की गई कुछ टाइपिंग त्रुटियां या यहां तक ​​कि कॉस्मेटिक त्रुटियों को यहां वर्गीकृत किया जा सकता है।

कभी-कभी प्राथमिकता कम होने के साथ दोष भी मौजूदा डिजाइन में कुछ वृद्धि या उपयोगकर्ता अनुभव को बढ़ाने के लिए एक छोटी सी सुविधा को लागू करने के अनुरोध के सुझाव के लिए खोले जाते हैं।

यह दोष भविष्य में हल किया जा सकता है और इस पर तत्काल ध्यान देने की आवश्यकता नहीं है कम गंभीरता दोष इस श्रेणी में आते हैं।

जैसा कि पहले से ही चर्चा की प्राथमिकता निर्धारित करती है कि दोष का समय कितनी जल्दी होना चाहिए। यदि कई दोष हैं, तो प्राथमिकता तय करती है कि किस दोष को ठीक करना है और तुरंत सत्यापित करना है कि कौन सा दोष थोड़ा बाद में तय किया जा सकता है।

दोष प्राथमिकता और गंभीरता का स्तर

गंभीरता क्या है?

गंभीरता उस सीमा को परिभाषित करती है, जो किसी विशेष दोष के कारण अनुप्रयोग या प्रणाली पर प्रभाव डाल सकती है।

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

उदाहरण के लिए, निम्नलिखित परिदृश्य पर विचार करें

  • यदि उपयोगकर्ता ऑनलाइन शॉपिंग करने की कोशिश करता है और एप्लिकेशन लोड नहीं होता है या सर्वर पर अनुपलब्ध संदेश नहीं आता है।
  • उपयोगकर्ता कार्ट में एक आइटम जोड़कर प्रदर्शन करता है, जोड़ी गई मात्रा गलत है / गलत उत्पाद जुड़ जाता है।
  • उपयोगकर्ता भुगतान करता है और भुगतान के बाद आदेश की पुष्टि के बजाय कार्ट में रहता है।
  • सिस्टम आदेश को स्वीकार करता है लेकिन अंत में, किसी भी मुद्दे के कारण आधे घंटे के बाद आदेश को रद्द कर देता है।
  • सिस्टम केवल एक क्लिक के बजाय डबल क्लिक पर 'कार्ट में जोड़ें' को स्वीकार करता है।
  • Add To Cart बटन को Add to Cart कहा जाता है।

यदि उपर्युक्त परिदृश्यों में से कोई भी हो सकता है, तो उपयोगकर्ता अनुभव क्या होगा?

मोटे तौर पर दोषों को इस प्रकार वर्गीकृत किया जा सकता है:

# 1) क्रिटिकल (S1)

एक दोष जो उत्पाद / सुविधा के पूरी तरह से बाधित या अवरुद्ध परीक्षण है, एक महत्वपूर्ण दोष है। एक उदाहरण यूआई परीक्षण के मामले में होगा जहां एक विज़ार्ड से गुजरने के बाद, यूआई केवल एक फलक में लटका हुआ है या फ़ंक्शन को ट्रिगर करने के लिए आगे नहीं जाता है। या कुछ अन्य मामलों में, जब विकसित की गई सुविधा बिल्ड से गायब है।

किसी भी कारण से, यदि एप्लिकेशन क्रैश हो जाता है या यह बेकार हो जाता है / आगे बढ़ने में सक्षम नहीं है, तो दोष को गंभीर गंभीरता के तहत वर्गीकृत किया जा सकता है।

किसी भी भयावह प्रणाली की विफलताएं उपयोगकर्ता को गैर-प्रयोज्य की ओर ले जा सकती हैं, जिन्हें गंभीर गंभीरता के तहत वर्गीकृत किया जा सकता है

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

ऊपर चर्चा की गई बिंदु 1 पर परिदृश्य को क्रिटिकल दोष के रूप में वर्गीकृत किया जा सकता है, क्योंकि ऑनलाइन आवेदन पूरी तरह से अनुपयोगी हो जाता है।

# 2) मेजर (S2)

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

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

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

मेल में CC अनुभाग के व्यवहार के बारे में क्या अपेक्षित है, यह उपयोगकर्ता को कई उपयोगकर्ता जोड़ने की अनुमति देनी चाहिए। इसलिए जब एप्लिकेशन की प्रमुख कार्यक्षमता ठीक से काम नहीं कर रही है या जब यह अपेक्षा से अलग व्यवहार करता है, तो यह एक प्रमुख दोष है।

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

कोई भी दोष जो गलत डेटा दृढ़ता, डेटा समस्या या गलत एप्लिकेशन व्यवहार को जन्म दे सकता है, को मोटे तौर पर मेजर गंभीरता के तहत वर्गीकृत किया जा सकता है।

# 3) लघु / मध्यम (S3)

लागू की गई कोई भी सुविधा जो उसकी आवश्यकताओं / उपयोग के मामले को पूरा नहीं कर रही है और अपेक्षा से भिन्न व्यवहार करती है, लेकिन प्रभाव कुछ हद तक नगण्य है या यह आवेदन पर एक बड़ा प्रभाव नहीं डालता है, को मामूली गंभीरता के तहत वर्गीकृत किया जा सकता है।

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

उदाहरण के लिए, याहू या जीमेल जैसे ईमेल सेवा प्रदाता में, 'नियम और शर्तें' नामक विकल्प होता है और उस विकल्प में, वेबसाइट की शर्तों और शर्तों के बारे में कई लिंक होंगे, जब कई लिंक में से कोई एक, ठीक काम नहीं कर रहा हो, इसे माइनर गंभीरता के रूप में कहा जाता है क्योंकि यह केवल एप्लिकेशन की छोटी कार्यक्षमता को प्रभावित करता है और इसका एप्लिकेशन की उपयोगिता पर बड़ा प्रभाव नहीं पड़ता है।

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

इस प्रकार के दोष के परिणामस्वरूप कार्यक्षमता या उपयोगकर्ता अनुभव का न्यूनतम नुकसान होता है।

# 4) कम (S4)

वर्तनी की गलतियों या संरेखण मुद्दों या फ़ॉन्ट आवरण सहित किसी भी कॉस्मेटिक दोष को कम गंभीरता के तहत वर्गीकृत किया जा सकता है।

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

उदाहरण के लिए, याहू या जीमेल जैसे ईमेल सेवा प्रदाता में, आपने 'लाइसेंस पृष्ठ' देखा होगा, अगर पृष्ठ में कोई वर्तनी की गलतियाँ या गलतफहमी है, तो इस दोष को निम्न के रूप में वर्गीकृत किया गया है।

ऊपर चर्चा की गई बिंदु 6 के परिदृश्य को निम्न दोष के रूप में वर्गीकृत किया जा सकता है, क्योंकि ऐड बटन गलत कैसिंग में प्रदर्शित होता है। इस तरह के दोष का सिस्टम व्यवहार या डेटा प्रस्तुति या डेटा हानि या डेटा प्रवाह या यहां तक ​​कि उपयोगकर्ता के अनुभव पर कोई प्रभाव नहीं पड़ेगा, लेकिन बहुत कॉस्मेटिक होगा।

दोष प्राथमिकता और गंभीरता

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

दोष का वर्गीकरण

उदाहरण

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

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

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

ऐसा प्रतीत हो रहा है कि ऐसा करने के लिए दो अलग-अलग उदाहरण हैं:

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

उदाहरण # 2) ऐसी कुछ स्थितियाँ हो सकती हैं जिनके तहत एक विशेष दोष उत्पन्न होता है जो ग्राहक के वातावरण में हिट होने की बहुत कम या कोई संभावना नहीं हो सकती है। भले ही कार्यक्षमता-वार यह एक परीक्षक को उच्च प्राथमिकता दोष की तरह लग सकता है, इसकी घटना की दुर्लभता और ठीक करने के लिए उच्च लागत को देखते हुए - इसे कम प्राथमिकता वाले दोष के रूप में वर्गीकृत किया जाएगा।

इसलिए प्रभाव में, दोष प्राथमिकता आम तौर पर उत्पाद प्रबंधक द्वारा 'दोष परीक्षण' बैठक में निर्धारित की जाती है।

अलग - अलग स्तर

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

आइए प्राथमिकता और गंभीरता दोनों के लिए विभिन्न स्तरों पर एक नज़र डालें।

  • उच्च प्राथमिकता, उच्च गंभीरता
  • उच्च प्राथमिकता, कम गंभीरता
  • उच्च गंभीरता, कम प्राथमिकता
  • कम गंभीरता, कम प्राथमिकता

निम्नलिखित आंकड़ा एकल स्निपेट में श्रेणियों के वर्गीकरण को दर्शाता है।

श्रेणियों का वर्गीकरण

(1) उच्च गंभीरता और उच्च प्राथमिकता

कोई भी क्रिटिकल / मेजर बिज़नेस केस फेल होने पर स्वतः ही इस श्रेणी में पदोन्नत हो जाता है।

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

उदाहरण के लिए,

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

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

# 2) उच्च प्राथमिकता और कम गंभीरता

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

दोष जिन्हें ठीक किया जाना है लेकिन इस श्रेणी के तहत आने वाले आवेदन को प्रभावित नहीं करते हैं।

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

उदाहरण के लिए,

फ्रंट-पेज में कंपनी का लोगो गलत है, ऐसा माना जाता है उच्च प्राथमिकता और कम गंभीरता दोष ।

उदाहरण 1) ऑनलाइन शॉपिंग वेबसाइट में जब फ्रंटपेज का लोगो गलत लिखा गया है, उदाहरण के लिए फ्लिपकार्ट के बजाय इसे फ्लिपकार्ट के रूप में लिखा गया है।

उदाहरण 2) बैंक लोगो में, ICICI के बजाय, ICCCI के रूप में लिखा जाता है।

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

# 3) उच्च गंभीरता और कम प्राथमिकता

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

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

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

उदाहरण के लिए,

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

हालांकि इस सुविधा में एक कार्यात्मक दोष है, क्योंकि यह सीधे अंतिम ग्राहकों को प्रभावित नहीं कर रहा है, एक व्यापार हितधारक कम प्राथमिकता के तहत दोष को वर्गीकृत कर सकता है, हालांकि यह आवेदन पर एक गंभीर कार्यात्मक प्रभाव है।

यह एक उच्च गंभीरता दोष है लेकिन इसे कम प्राथमिकता के लिए प्राथमिकता दी जा सकती है क्योंकि इसे अगली रिलीज़ के साथ परिवर्तन अनुरोध के रूप में तय किया जा सकता है। व्यावसायिक हितधारक भी इस सुविधा को शायद ही कभी इस्तेमाल की जाने वाली विशेषता के रूप में प्राथमिकता देते हैं और किसी भी अन्य सुविधाओं को प्रभावित नहीं करते हैं जो उपयोगकर्ता के अनुभव पर सीधा प्रभाव डालते हैं। इस तरह के दोष को इसके अंतर्गत वर्गीकृत किया जा सकता है उच्च गंभीरता लेकिन कम प्राथमिकता वर्ग।

# 4) कम गंभीरता और कम प्राथमिकता

3 के पैराग्राफ में कोई वर्तनी की गलतियाँ / फ़ॉन्ट आवरण / मिसलिग्न्मेंटतृतीयया ४धआवेदन का पृष्ठ और मुख्य या फ्रंट पेज / शीर्षक में नहीं।

इन दोषों को हरे रंग की रेखाओं में वर्गीकृत किया जाता है जैसा कि चित्र में दिखाया गया है और तब होता है जब कोई कार्यक्षमता प्रभाव नहीं होता है, लेकिन फिर भी मानकों को एक छोटी सी डिग्री तक पूरा नहीं करता है। आमतौर पर यूआई पर एक तालिका में कॉस्मेटिक त्रुटियों या सेल के आयामों को यहां वर्गीकृत किया गया है।

उदाहरण के लिए,

यदि वेबसाइट की गोपनीयता नीति में वर्तनी की गलती है, तो यह दोष इस प्रकार है कम गंभीरता और कम प्राथमिकता।

दिशा-निर्देश

नीचे कुछ दिशानिर्देश दिए गए हैं जिन्हें हर परीक्षक को पालन करने की कोशिश करनी चाहिए:

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

निष्कर्ष

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

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

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

अनुशंसित पाठ

^