मॉड्यूल 4 · टेस्ट प्रोसेस (STLC)

एंट्री और एग्ज़िट क्राइटेरिया

Mutqan Soft QA टीम द्वारा · · 18 मिनट · शुरुआती

Entry criteria वे शर्तें हैं जो किसी test activity के शुरू होने से पहले पूरी होनी चाहिए; exit criteria वे शर्तें हैं जो उसे पूरा घोषित करने से पहले पूरी होनी चाहिए। उदाहरण के लिए, system testing तब शुरू हो सकती है जब build test environment पर deploy हो, smoke tests पास हों और test data load हो, और तब ख़त्म हो सकती है जब हर High-risk test case पास हो चुका हो और कोई Blocker या Critical defect open न हो।

Criteria test planning के दौरान लिखे जाते हैं, testing चलते समय test monitoring उनके मुकाबले progress जाँचती है, और exit criteria का मूल्यांकन होने के बाद test completion शुरू होता है। Test plans में आम तौर पर suspension criteria भी होते हैं, जो बताते हैं कि testing कब रोकनी है, और resumption criteria, जो बताते हैं कि दोबारा शुरू करने से पहले क्या सच होना चाहिए; ISO/IEC/IEEE 29119-3 में बताए गए test plan में इन चारों के लिए जगह है। ISTQB glossary test completion criteria को exit criteria का दूसरा नाम भी बताती है।

यह क्यों ज़रूरी है

Entry criteria के बिना शुरू करने का मतलब है ऐसा build टेस्ट करना जो testable ही नहीं: login fail होता है, कोई integration गायब है, data गलत है। Testers environment से हुई failures report करने में घंटों गँवाते हैं, और नतीजों पर कोई भरोसा नहीं करता। ISTQB Foundation syllabus बताता है कि अपने entry criteria पूरे किए बिना शुरू हुई activity के ज़्यादा कठिन, धीमी, महँगी और जोखिम भरी होने की संभावना रहती है।

Exit criteria के बिना "done" deadline तय करती है या वह व्यक्ति जो सबसे देर तक बहस करे। पहले से तय criteria product owner को release decision के लिए तथ्य देते हैं, और tester को "अभी नहीं" कहने का निष्पक्ष तरीका देते हैं।

Entry criteria: क्या activity शुरू होने के लिए तैयार है?

ISTQB syllabus आम entry criteria को तीन प्रकारों में बाँटता है: resources की उपलब्धता (लोग, tools, environments, test data, budget, समय), testware की उपलब्धता (test basis, testable requirements, user stories, test cases) और test object की शुरुआती quality, जैसे passed smoke tests। ये हर test level के लिए अलग तय होने चाहिए और उसके test objectives के हिसाब से बदलते हैं, इसलिए component testing के entry criteria acceptance testing के entry criteria से अलग होते हैं।

अगर कोई entry criterion पूरा नहीं है, तो team तय करती है कि क्या करना है: इंतज़ार करें, सिर्फ़ वे हिस्से शुरू करें जिन पर असर नहीं (UI build टूटा हो तो API tests), या जोखिम दर्ज करके और criteria तय करने वाले लोगों की स्वीकृति लेकर फिर भी शुरू करें।

  • Environment: release candidate test environment पर deploy है और हर service का health check सफल है।
  • शुरुआती quality: उस build पर smoke suite 25 में से 25 tests पास करता है।
  • Testware और data: सभी High-risk requirements के test cases peer-review हो चुके हैं, और 50 test customer accounts load हैं, जिनमें Arabic नाम और expired cards शामिल हैं।

आज़माएँ: API हेल्थ चेकर

Exit criteria: क्या activity पूरी हो गई?

Syllabus exit criteria के दो प्रकार बताता है। Measures of thoroughness बताते हैं कि कितना हासिल हुआ: पहुँचा हुआ coverage, unresolved defects, defect density, failed test cases। Binary yes/no criteria बताते हैं कि कोई काम हुआ या नहीं: planned tests execute हुए, static testing हुई, मिला हर defect report हुआ, regression tests automate हुए। CTFL v4.0 के पहले edition ने इस दूसरे प्रकार को completion criteria कहा था; v4.0.1 ने इसका नाम बदला ताकि इसे पूरे exit criteria से न मिलाया जाए।

Sequential development models में एक test level के exit criteria अक्सर अगले level के entry criteria का हिस्सा होते हैं, जैसे जब system testing काम acceptance testing को सौंपती है; कुछ iterative models में ऐसा नहीं होता। समय या budget ख़त्म होने से भी testing रुक सकती है, लेकिन सिर्फ़ तब जब stakeholders ने बिना और testing के live जाने के जोखिम को review करके स्वीकार किया हो। अधूरे criteria और वह स्वीकृति दर्ज करें।

आज़माएँ: Requirements → टेस्ट केस आज़माएँ: प्रतिशत कैलकुलेटर

Suspension और resumption criteria

Suspension criteria वे हालात बताते हैं जिनमें testing जारी रखना मेहनत की बर्बादी है या ऐसे नतीजे देता है जिन पर कोई भरोसा न करे; resumption criteria बताते हैं कि testing दोबारा शुरू होने से पहले क्या सच होना चाहिए। Suspend करना test monitoring और control वाले lesson के फ़ैसलों जैसा एक test control फ़ैसला है: monitoring trigger दिखाती है, और control उस पर कार्रवाई करता है। Criteria जोड़ों में लिखें:

  • नए build पर smoke suite fail हो तो suspend करें; ठीक किया हुआ build उसे पास करे तो resume करें।
  • Test environment या ज़रूरी sandbox 4 working hours से ज़्यादा बंद रहे तो suspend करें; वह बहाल हो और उसके health checks पास हों तो resume करें।
  • एक defect बचे हुए test cases में से 30% से ज़्यादा को block करे तो suspend करें; उसका fix confirmation testing में पास हो तो resume करें।
  • Resume करते समय जो tests चल रहे थे उन्हें दोबारा चलाएँ, और गँवाया समय अगली progress report में दर्ज करें।
इस lesson के उदाहरण criteria के साथ test activity entry criteria पूरे होने पर "तैयार नहीं" से "टेस्टिंग जारी" में जाती है, resumption criterion पूरा होने तक "रुकी हुई" रहती है, और exit criteria पूरे होने पर पूरी होती है।
ट्रांज़िशन
#सेतकCriterion
1तैयार नहींशुरुआतटेस्टिंग जारीEntry criteria पूरे: release candidate deploy और health checks पास, smoke suite 25 में से 25 पास, test cases review हुए और test data load हुआ
2टेस्टिंग जारीरुकी हुईSuspension criterion लागू: नए build पर smoke fail, environment या sandbox 4 working hours से ज़्यादा बंद, या एक defect बचे हुए tests में से 30% से ज़्यादा को block करे
3रुकी हुईटेस्टिंग जारीResumption criterion पूरा: ठीक किया build smoke पास करे, environment बहाल होकर health checks पास करे, या fix confirmation testing में पास हो; जो tests चल रहे थे वे दोबारा चलते हैं
4टेस्टिंग जारीपूरीअंतBuild under test पर सभी exit criteria पूरे
5टेस्टिंग जारीपूरीअंतसमय या budget ख़त्म: stakeholders अधूरे criteria review करके जोखिम स्वीकार करते हैं, और यह स्वीकृति दर्ज होती हैवैकल्पिक पथ

Thresholds इसी lesson के उदाहरण हैं। पूरी होने का मतलब है कि test activity ख़त्म हुई; release decision फिर भी stakeholders का है।

ऐसे criteria जिन्हें दो लोग एक जैसा आँकें

Criterion तभी काम करता है जब एक ही data देखने वाले दो लोग एक ही हाँ या ना पर पहुँचें। हर criterion को एक measure, एक threshold, data का source (test management tool, defect tracker, CI run) और वह build दें जिस पर वह लागू होता है। High-risk test cases वाले criteria के लिए risk levels भी testing से पहले तय होने चाहिए।

  • "Build stable है" → "build under test पर smoke suite 25 में से 25 tests पास करता है"।
  • "Testing पूरी है" → "सभी High-risk test cases पास हुए और planned test cases में से कम से कम 95% execute हुए"।
  • "कोई बड़े bugs नहीं" → "कोई open Blocker या Critical defect नहीं; हर open Major defect का स्वीकार किया गया workaround है"।
  • "अच्छा coverage" → "scope की हर requirement का कम से कम एक passed test case है"।
  • "Performance ठीक है" → "200 concurrent users के साथ 95% searches 2.0 सेकंड या उससे कम में response देती हैं (p95)"।

आज़माएँ: रिस्क-बेस्ड टेस्ट जनरेटर

Worked example: release से पहले exit criteria की जाँच

एक food delivery app का release 3.5 scheduled orders जोड़ता है। उसके system test plan में छह exit criteria हैं: सभी High-risk test cases execute और पास, 150 planned test cases में से कम से कम 95% execute, कोई open Blocker या Critical defect नहीं, अधिकतम 3 open Major defects, release candidate पर regression suite पास, और scope की हर requirement किसी passed test से covered। Day 9 के अंत में test lead हर criterion को test management tool और defect tracker के data से मिलाता है।

Release 3.5 का day 9 के अंत में exit check: छह measurable criteria में से चार पूरे हैं, पर 95% target के मुकाबले 94% execution और एक open Critical defect system testing को अधूरा रखते हैं।
Exit criterionTargettest plan में तयActualday 9 का अंतअगला कदम
High-risk test cases execute और पास100%38 में से 38पासकोई अतिरिक्त कार्रवाई नहीं
Planned test cases executeकम से कम 95%150 में से 141 (94%)फ़ेलबचे 9 Low-risk cases चलाएँया product owner कमी को लिखित में स्वीकार करे
Open Blocker या Critical defects01 Criticalफ़ेलDouble charge ठीक करेंफिर defect का confirmation test
Open Major defectsअधिकतम 32पासकोई अतिरिक्त कार्रवाई नहीं
Release candidate पर regression suiteसब पास212 में से 212पासFix वाले build पर दोबारा चलाएँ
Passed test वाली in-scope requirements100%27 में से 27पासकोई अतिरिक्त कार्रवाई नहीं

मान lesson के उदाहरण से हैं। Fix के बाद सभी छह criteria नए release candidate पर दोबारा जाँचे जाते हैं।

  • पूरे: 38 में से 38 High-risk cases पास, 2 Major defects open, regression suite 212 में से 212 पास, और सभी 27 requirements का passed test है।
  • पूरा नहीं: 150 में से 141 execute यानी 94%। बचे 9 cases order history की Low-risk जाँचें हैं, इसलिए या तो team उन्हें एक और दिन में चलाए, या product owner इस कमी को लिखित में स्वीकार करे।
  • पूरा नहीं: day 8 के एक exploratory session में पता चला कि scheduled order का time slot बदलने पर card से दो बार पैसे कटते हैं। ग्राहकों से दो बार पैसे काटने वाला Critical defect product owner स्वीकार नहीं करेगा, इसलिए पहले fix।
  • Fix से नया release candidate बनता है। Tester defect का confirmation test करता है, regression suite दोबारा चलाता है, उस build पर सभी छह criteria फिर जाँचता है और नतीजा test completion report में दर्ज करता है।
पाठ संस्करण
Release 3.5, system testing: exit criteria at the end of day 9

Criterion                                   Target      Actual           Met
High-risk test cases executed and passed    100%        38/38 (100%)     yes
Planned test cases executed                 >= 95%      141/150 (94%)    no
Open Blocker or Critical defects            0           1 Critical       no
Open Major defects                          <= 3        2                yes
Regression suite on the release candidate   all pass    212/212          yes
In-scope requirements with a passed test    100%        27/27            yes

आम गलतियाँ

  • "testing काफ़ी है" या "build stable है" जैसे vague criteria।
  • हर test level और activity के लिए अलग set की बजाय पूरे project के लिए criteria का एक ही set।
  • Entry criteria पूरे न करने वाले build पर बिना बताए शुरू करना, और फिर environment की समस्याओं को product defects बताकर report करना।
  • आख़िर में threshold घटाना या defect की severity कम करना ताकि criteria पूरे दिखें, बजाय कमी report करने के।
  • Resumption criteria के बिना suspension criteria, जिससे testing ऐसे build पर दोबारा शुरू होती है जिसका smoke test नहीं हुआ, और फिर रुक जाती है।
  • Exit criteria पूरे होने को इस बात का सबूत मानना कि कोई defect नहीं है; वे सिर्फ़ दिखाते हैं कि तय स्तर की testing हो गई।

QA का नज़रिया

Tester या test lead test plan लिखते समय criteria प्रस्तावित करता है, और testing शुरू होने से पहले product owner, development lead और project manager के साथ उन पर सहमति बनाता है। हर criterion के लिए पूछें: आँकड़ा कहाँ से आएगा, उसे कौन जाँचेगा, और पूरा न होने पर फ़ैसला कौन करेगा?

Execution के दौरान हर progress report में criteria की स्थिति दिखाएँ ("exit criteria: 6 में से 4 पूरे") ताकि release के दिन कोई surprise न हो, और हर suspension को उसके कारण, build और समय के साथ दर्ज करें। Test completion report हर criterion को उसकी actual value के साथ और हर deviation को स्वीकार करने वाले के नाम के साथ लिखती है। Tester तथ्य report करता है; release decision stakeholders का है।

अभ्यास

Password reset feature के criteria लिखें और जाँचें

आपका काम

एक mobile banking app SMS से भेजे गए one-time code के ज़रिए password reset जोड़ता है। System testing का दो हफ़्ते का एक cycle है, जिसमें 60 planned test cases हैं, उनमें से 15 High risk, जो 8 acceptance criteria cover करते हैं। Testing एक SMS gateway sandbox पर निर्भर है।

Day 10 के अंत की स्थिति: 60 में से 57 cases execute हुए और 54 पास; 15 में से 15 High-risk cases execute हुए और 14 पास; open defects: 1 Critical और 2 Minor। Day 7 पर SMS sandbox 6 working hours बंद रहा और testing चलती रही। इस test level के लिए criteria लिखें, फिर तय करें कि testing पूरी हुई या नहीं।

चरण
  1. तीन entry criteria लिखें: resources, testware और build की शुरुआती quality के लिए एक-एक।
  2. चार measurable exit criteria लिखें।
  3. दो suspension criteria लिखें, हर एक के साथ उससे मेल खाता resumption criterion।
  4. Day 10 की स्थिति को अपने exit criteria से मिलाएँ।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Entry (उदाहरण): SMS sandbox 60 सेकंड के अंदर test number पर code पहुँचाता है; सभी 60 test cases review होकर 8 acceptance criteria से trace हैं; build पर smoke suite 10 में से 10 पास करता है।

Exit (उदाहरण): सभी 15 High-risk cases execute और पास; planned cases में से कम से कम 95% execute; कोई open Blocker या Critical defect नहीं; हर acceptance criterion किसी passed test case से covered।

Suspension और resumption: नए build पर smoke fail हो तो suspend, ठीक किया build उसे पास करे तो resume; sandbox 4 working hours से ज़्यादा बंद रहे तो suspend, बहाल होकर code पहुँचाने लगे तो resume।

मूल्यांकन: 60 में से 57 यानी 95%, इसलिए execution पूरा है। लेकिन 15 में से सिर्फ़ 14 High-risk cases पास हैं और एक Critical defect open है, इसलिए testing पूरी नहीं: defect को fix, confirmation test और reset flow का regression run चाहिए, फिर criteria दोबारा जाँचें। 2 Minor defects इनमें से कोई criterion नहीं तोड़ते। 8 acceptance criteria का coverage इस स्थिति से नहीं आँका जा सकता, इसलिए हाँ या ना कहने से पहले traceability data माँगें। 6 घंटे का outage 4 घंटे की threshold से ज़्यादा था, इसलिए sandbox पर निर्भर testing suspend होनी चाहिए थी। Outage के दौरान जिन tests को SMS code चाहिए था उन्हें दोबारा चलाएँ, और जाँचें कि 3 failed cases में से कोई defect की बजाय outage की वजह से तो fail नहीं हुआ।

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

Entry और exit criteria कौन तय करता है?

आम तौर पर test lead या tester test planning के दौरान उन्हें प्रस्तावित करता है, और stakeholders (product owner, development lead, project manager) testing शुरू होने से पहले उन पर सहमत होते हैं। वे test plan में लिखे जाते हैं। किसी अधूरे criterion के साथ आगे बढ़ने या release करने का फ़ैसला stakeholders का है, अकेले tester का नहीं।

क्या exit criteria और acceptance criteria एक ही हैं?

नहीं। Acceptance criteria वे शर्तें हैं जिन्हें किसी user story या product को स्वीकार होने के लिए पूरा करना है, यानी वे product का व्यवहार बताती हैं। Exit criteria किसी test activity को पूरा करने की शर्तें हैं, जैसे पहुँचा हुआ coverage और resolved defects। एक आम exit criterion यही है कि हर acceptance criterion किसी passed test से covered हो।

Definition of Ready और Definition of Done से इनका क्या संबंध है?

ISTQB syllabus बताता है कि Agile development में exit criteria को अक्सर Definition of Done कहा जाता है, और वे entry criteria जिन्हें किसी user story को development या testing शुरू होने से पहले पूरा करना होता है, Definition of Ready कहलाते हैं। Definition of Ready और Definition of Done वाला lesson दोनों को समझाता है।

क्या कोई exit criterion पूरा न होने पर भी product release हो सकता है?

हो सकता है, अगर stakeholders अधूरे criteria review करके बचा हुआ जोखिम स्वीकार करें, जैसे 9 Low-risk test cases जो execute नहीं हुए। Test completion report में लिखें कि कौन-से criteria पूरे नहीं हुए, क्यों, और जोखिम किसने स्वीकार किया। Exit criteria release decision को जानकारी देते हैं, फ़ैसला नहीं करते।

संदर्भ

  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
  • ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
  • ISO/IEC/IEEE 29119-3:2021 — Software and systems engineering — Software testing — Part 3: Test documentationISO/IEC/IEEE · 2021टेस्ट दस्तावेज़ों के टेम्पलेट और सामग्री — test policy, strategy, plan, status व completion रिपोर्ट, incident रिपोर्ट।
टूल्स

Mutqan tools से अभ्यास करें

Requirements → टेस्ट केस

क्रमांकित आवश्यकताओं की सूची को requirement-to-test मैट्रिक्स के साथ ट्रेस करने योग्य टेस्ट केस में बदलें।

टेस्ट डिज़ाइन

रिस्क-बेस्ड टेस्ट जनरेटर

फ़ीचर को संभावना और प्रभाव के आधार पर स्कोर दें, फिर प्राथमिकता वाला risk-based टेस्ट प्लान जनरेट करें।

टेस्ट डिज़ाइन

प्रतिशत कैलकुलेटर

प्रतिशत, प्रतिशत परिवर्तन, वृद्धि/कमी और X, Y का कितना प्रतिशत है — सब गिनें।

यूटिलिटीज़

API हेल्थ चेकर

एक साथ कई API health endpoint जाँचें और स्टेटस, latency तथा pass/fail सारांश पाएँ।

API टेस्टिंग

और गहराई से

इस topic में आपकी प्रगति

QA रोडमैप का हिस्सा