मेन्यू

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

when stop testing

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

परीक्षण में निकास मानदंड:

'अच्छी तरह से शुरू हो गया आधा हो गया है' - हर जगह लागू होता है, यहां तक ​​कि सॉफ्टवेयर परीक्षण भी।

अक्सर हम प्रोजेक्ट की शुरुआत में सॉफ्टवेयर टेस्टर को बहुत उत्साही देखते हैं। हम बनाते हैं दस्तावेजों का परीक्षण जैसे कि टेस्ट स्ट्रेटेजी, टेस्ट प्लान या टेस्ट केस उत्सुकता और उत्साह से।

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

परीक्षण कब रोकना है

जैसा कि हम दोषों का भार पाते हैं और पहले चरण को पूरा करते हैं जिसे हम अगले चरण पर ले जाते हैं। जब हम दूसरे भाग में पहुँचते हैं तो हम आराम करते हैं और जैसा कि सामान्य मानव प्रवृत्ति है एक ही चीज़ के परीक्षण से ऊब जाना दूसरे रन में।

शीर्ष 50 sql मुश्किल साक्षात्कार साक्षात्कार पीडीएफ

कई परीक्षकों को लगता है कि यह बन जाता है नीरस काम बाद में चलाता है और एक ही सॉफ्टवेयर का बार-बार परीक्षण करने में रुचि खोने लगता है। जब हम पहुंचते हैं, तो शायद तीसरा भाग, एक प्रश्न हमें परेशान करना शुरू कर देता है और वह यह है कि 'सॉफ्टवेयर का परीक्षण कब रोकें?'

मुझे यकीन है कि आपने उसी तरह महसूस किया होगा और पूछा था, 'जब परीक्षण बंद करना है?', तो कम से कम एक बार। मैं कहूंगा सवाल है 'कब, कहाँ और कैसे परीक्षण रोकें?' :)

वैचारिक रूप से हमने पढ़ा है और कई परीक्षकों का मानना ​​है कि 'परीक्षण कब रोकना है' यह तय करने के लिए कोई विशिष्ट शर्त या समीकरण नहीं हो सकता है? इस प्रश्न पर निष्कर्ष निकालने से पहले कई कारकों पर विचार करना होगा।

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

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

यह पर्याप्त परीक्षण कब है?

हम कब कह सकते हैं कि यह बहुत परीक्षण पर्याप्त है? क्या परीक्षण कभी पूरा हो सकता है?

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

आइए एक नए प्रोजेक्ट का परीक्षण शुरू करें।

प्रारंभिक गतिविधियाँ:

  • परीक्षण टीम आवश्यकताओं को प्राप्त करता है।
  • परीक्षण दल शुरू होता है योजना और डिजाइनिंग।
  • प्रारंभिक परीक्षण दस्तावेज तैयार हैं और समीक्षा की गई है।

परीक्षण रन # 1)

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

परीक्षण रन # 2)

  • परीक्षण टीम परीक्षण के दूसरे रन को शुरू करती है और इसी तरह की गतिविधियों को रन 1 के रूप में निष्पादित किया जाता है।
  • इस प्रक्रिया में दूसरे परीक्षण रन के दौरान, कुछ और दोष पकड़े जाते हैं।
  • दोष डेवलपर्स द्वारा तय किए जाते हैं और टेस्ट टीम में एक वापसी के लिए वापस आ जाते हैं।
  • परीक्षण टीम दोषों और प्रदर्शनों का पुन: परीक्षण करती है वापसी ।

यह हमेशा के लिए जारी रह सकता है। 3 चलाएं, 4 रन करें जब तक कि सॉफ्टवेयर में सभी दोष नहीं मिलते हैं और सॉफ्टवेयर बग-रहित हो जाता है।

यदि हम इन गतिविधियों के लिए एक प्रवाह चार्ट बनाना चाहते हैं, तो यह नीचे की तरह दिखाई देगा:

टेस्ट रन फ्लो चार्ट

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

लेकिन सवाल यह है - क्या सॉफ्टवेयर में हर एक दोष का पता लगाना संभव है? आइए इस मिलियन डॉलर के प्रश्न का उत्तर खोजने की कोशिश करें :)।

सभी दोष पाए जाने पर रोकना: क्या यह संभव है?

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

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

इसके अलावा, परीक्षण का उद्देश्य सॉफ़्टवेयर के प्रत्येक दोष का पता लगाना नहीं है। सॉफ्टवेयर परीक्षण का आशय यह साबित करना है कि सॉफ्टवेयर इसे तोड़कर या अपने वर्तमान व्यवहार और अपेक्षित व्यवहार के बीच विचलन का पता लगाने के उद्देश्य से काम करता है।

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

ईमानदारी से बोलें, परीक्षण अंतहीन है और परीक्षण चक्र तब तक जारी रहेगा जब तक कोई निर्णय नहीं किया जाता है कि कब और कहां रोकना है। अब परीक्षण को रोकने के निर्णय पर आना और भी जटिल हो गया है। यदि 'सभी दोष पाए जाने पर रोक' परीक्षण को रोकने की कसौटी नहीं है तो इसे किस आधार पर तय किया जाना चाहिए?

परीक्षण बंद करने का निर्णय: मापदंड से बाहर निकलें

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

सबसे आम दृष्टिकोण यह है कि या तो समय / बजट समाप्त हो जाए या सभी परीक्षण परिदृश्य निष्पादित हो जाएं। हालांकि, इस दृष्टिकोण के साथ, हम परीक्षण की गुणवत्ता पर समझौता करेंगे और इससे सॉफ्टवेयर के बारे में पर्याप्त विश्वास नहीं होगा; कैसे?

चलो एक साथ देखते हैंउदाहरण।

परीक्षण परिदृश्य:

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

परिद्रश्य 1)

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

सप्ताह के अंत में, आप कुछ अधिक महत्वपूर्ण उच्च के साथ 20 परिदृश्यों को पूरा करते हैं प्राथमिकता दोष ।

सप्ताह 2: आप दोष खोजने पर अधिक ध्यान केंद्रित करते हुए सॉफ्टवेयर का परीक्षण शुरू करते हैं। आप दूसरे सप्ताह के दौरान कुछ और गंभीरता 1, गंभीरता 2 और गंभीरता 3 दोषों को खोलते हैं और सप्ताह के अंत में, आप 70 परिदृश्यों को कवर करने में सक्षम होते हैं।

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

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

सप्ताह 4: सप्ताह 4 तक आपको अधिकांश खुले हुए दोषों और शेष 80 परिदृश्यों का फिर से परीक्षण करना होगा। सप्ताह 4 के अंत तक, आप निर्धारित और पुन: परीक्षण किए गए सभी उच्च और मध्यम प्राथमिकता वाले दोषों के साथ 180 परिदृश्यों को पूरा करने में सक्षम हैं।

इस जानकारी को सारणीबद्ध रूप में लाना:

हफ्तोंटेस्ट एक्टिविटीज की गईसप्ताह के अंत में परिणाम
सप्ताह 1• दिन 1 - शो स्टॉपर दोष मिला।
• परीक्षण 1 दिन में पाया गया 1 गंभीरता के कारण अवरुद्ध है।
• अवरोधक दोष 4 दिन पर हल किया गया।
• परीक्षण निष्पादन 1 सप्ताह के अंत तक जारी रहा।		• उच्च प्राथमिकता / महत्वपूर्ण दोष खोले गए।
• 20 परिदृश्य पूरे।
सप्ताह २• दोष खोजने पर अधिक ध्यान केंद्रित करना।
• शेष परीक्षण परिदृश्यों का निष्पादन।
• निश्चित दोषों का पुन: परीक्षण।		• कुछ अधिक गंभीरता 1, गंभीरता 2 और गंभीरता 3 दोष खुल गए।
• कुल कवर 70 परिदृश्य कवर।
सप्ताह 3• सभी उच्च प्राथमिकता वाले दोषों का पुन: परीक्षण।
• शेष परीक्षा परिदृश्यों का निष्पादन।
• केवल गंभीरता 3 दोष पाया जाना बाकी है।		• कुछ अधिक गंभीरता 1, गंभीरता 2 और गंभीरता 3 दोष खुल गए।
• कुल कवर 120 परिदृश्य कवर किए गए।
सप्ताह 4• सभी उच्च और मध्यम प्राथमिकता दोषों का पुन: परीक्षण।
• शेष परीक्षण परिदृश्यों का निष्पादन।		• कुछ अधिक गंभीरता 3 दोष खुल गए।
• कुल कवर 180 परिदृश्य कवर।

क्या आपको यहां रुकना चाहिए?

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

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

परिदृश्य # 2)

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

सप्ताह के अंत में, आप कुछ और दोषों के साथ 20 परिदृश्यों को पूरा करते हैं। यह सप्ताह परिदृश्य 1 जैसा ही रहता है।

सप्ताह 2: आप दूसरे सप्ताह के दौरान कुछ और गंभीरता 1, गंभीरता 2 और गंभीरता 3 दोषों को खोलते हैं, लेकिन ध्यान दें कि सप्ताह 1 से बैकलॉग को कवर करने के लिए अधिक परिदृश्यों को कवर करना है। सप्ताह के अंत में, आप 120 परिदृश्यों को कवर करने में सक्षम हैं।

सप्ताह 3: 3 की शुरुआत तकतृतीयसप्ताह में आपको सभी खुले हुए दोषों का समाधान मिल जाता है इसलिए लंबित परिदृश्यों के निष्पादन के साथ-साथ अब आपको उन सभी दोषों का फिर से परीक्षण करना होगा जो एक परीक्षण बाल्टी में उतारे गए हैं। अभी भी अच्छी प्रगति के साथ अंत में जारी रहने वाले परिदृश्यों में से कोई भी अतिरिक्त दोष के साथ 200 हो जाता है।

अब आप केवल गंभीरता 2 और गंभीरता 3 दोषों की रिपोर्ट कर सकते हैं।

इस जानकारी को सारणीबद्ध रूप में लाना:

हफ्तोंटेस्ट एक्टिविटीज की गईसप्ताह के अंत में परिणाम
सप्ताह 1• दिन 1 - शो स्टॉपर दोष पाया।
• परीक्षण 1 दिन में पाया गया 1 गंभीरता के कारण अवरुद्ध है।
• अवरोधक दोष दिन 4 पर हल हुआ।
• परीक्षण निष्पादन सप्ताह के अंत तक जारी रहा।		• उच्च प्राथमिकता / महत्वपूर्ण दोष खोले गए।
• 20 परिदृश्य पूरे।
सप्ताह २• पिछले सप्ताह से बैकलॉग को कवर करने के लिए अधिक परिदृश्य निष्पादित करने पर ध्यान केंद्रित किया गया है।
• फिक्स्ड दोषों का पुन: परीक्षण।		• कुछ अधिक गंभीरता 1, गंभीरता 2 और गंभीरता 3 दोष खुले।
• कुल कवर 120 परिदृश्य कवर किए गए।
सप्ताह 3• सभी उच्च प्राथमिकता वाले दोषों का पुन: परीक्षण।
• शेष परीक्षा परिदृश्यों का निष्पादन।
• केवल गंभीरता 3 और कुछ गंभीरता 2 दोष पाया जाना बाकी है।		• कुछ अधिक गंभीरता 1, गंभीरता 2 और गंभीरता 3 दोष खुले।
• सभी परिदृश्यों को कवर किया गया।

क्या आपको यहां रुकना चाहिए?

आपके पास पूरी तरह से सभी परीक्षण परिदृश्यों को कवर किया एक बार और कुछ प्रमुख दोष खोले हैं। क्या इस बिंदु पर रोक आपको सॉफ़्टवेयर के बारे में विश्वास दिलाएगा?

नीचे दिए गए कारणों के कारण वास्तव में नहीं:

  • सभी परिदृश्यों को केवल एक बार निष्पादित किया जाता है।
  • सॉफ्टवेयर में अभी भी कई प्रमुख दोष हैं।
  • प्रतिगमन को कवर नहीं किया जाता है।

हम देख सकते हैं कि दोनों परिदृश्यों के ऊपर गुणवत्ता में समझौता किया गया है। सबसे अच्छा दृष्टिकोण एक बिंदु ढूंढना होगा जहां परिदृश्य 1 और परिदृश्य 2 से सभी कारक शामिल हैं और गुणवत्ता से भी समझौता नहीं किया गया है। इसे प्राप्त करने के लिए हमें परीक्षण की शुरुआत में कुछ मानदंडों को परिभाषित करना होगा।

इन मानदंडों को पूर्णता या निकास मानदंड कहा जाता है। यह हमारे सवाल का जवाब है - 'परीक्षण कब रोकना है?'।

पूर्णता या निकास मानदंड क्या है?

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

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

एग्जिट मानदंड में क्या मौजूद होना चाहिए?

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

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

परीक्षण को रोका जा सकता है जब:

आवश्यकताएँ:

  • 100% आवश्यकताएँ कवरेज हासिल की है।

दोष के:

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

टेस्ट कवरेज:

मैन्युअल परीक्षण में वेब अनुप्रयोग के लिए परीक्षण के मामले
  • टेस्ट कवरेज 95% हासिल किया जाना चाहिए।
  • टेस्ट केस पास दर 95% होनी चाहिए। इसकी गणना सूत्र द्वारा की जा सकती है
    • (टीसी की कुल संख्या उत्तीर्ण / टीसी की कुल संख्या) * 100।
  • सभी महत्वपूर्ण परीक्षण मामले पारित किए जाते हैं।
  • 5% टेस्ट केस फेल हो सकते हैं लेकिन फेल टेस्ट के मामले कम प्राथमिकता के होते हैं।
  • पूर्ण कार्यात्मक कवरेज हासिल किया जाता है।
  • सभी प्रमुख कार्यात्मक / व्यावसायिक प्रवाह विभिन्न इनपुट के साथ सफलतापूर्वक निष्पादित किए जाते हैं और ठीक काम कर रहे हैं।

समय सीमा:

  • प्रोजेक्ट डेडलाइन या टेस्ट फिनिश की समय सीमा समाप्त हो गई है।

टेस्ट दस्तावेज़:

  • सभी टेस्ट दस्तावेज़ / डिलिवरेबल्स (उदाहरण - टेस्ट सारांश रिपोर्ट ) तैयार किए जाते हैं, उनकी समीक्षा की जाती है और उन्हें प्रकाशित किया जाता है।

बजट:

  • पूरा परीक्षण बजट समाप्त हो गया है।

'गो / नो गो' बैठकें:

  • ' गो / नो गो ' मुलाकात हितधारकों के साथ आयोजित किया गया है और एक निर्णय किया जाता है कि परियोजना को उत्पादन में जाना चाहिए या नहीं।

निष्कर्ष:

चलो अंत में इसे बहुत सरल बनाते हैं।

कृपया एक साधारण हां या नहीं के साथ सवालों के जवाब दें

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

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

लेखक के बारे में: यह रेणुका के द्वारा एक अतिथि लेख है। वह सॉफ्टवेयर परीक्षण के 11+ वर्ष का अनुभव प्राप्त कर रही है।

आशा है कि यह लेख आपके लिए उपयोगी था। मैं इस विषय पर आपके विचारों / टिप्पणियों को सुनना चाहूंगा।

खुश परीक्षण!

अनुशंसित पाठ

^