टेस्ट कम्प्लीशन और क्लोज़र
Test completion test process की आख़िरी activity है। यह किसी milestone पर होती है — release, iteration या किसी test level का अंत — और test execution को ऐसे नतीजों में बदलती है जिन्हें टीम बाद में इस्तेमाल कर सके: हर open defect पर फ़ैसला, archive या hand over किया गया testware, तय स्थिति में छोड़ा गया test environment, lessons learned और test completion report। पुराने syllabi और कई टीमें इसे test closure या test cycle closure कहती हैं; ISTQB CTFL v4.0 इसे test completion कहता है।
उदाहरण: checkout टीम सोमवार को release 3.4 ship करती है। मंगलवार को tester दो unfixed defects को product backlog में ले जाता है, नए API tests regression suite में जोड़ता है, staging से temporary admin accounts हटाता है, lessons learned पर छोटी चर्चा करता है और completion report product owner, development lead और support lead को भेजता है।
यह क्यों ज़रूरी है
Completion के बिना testing से बनी बहुत-सी चीज़ें खो जाती हैं। Unfixed defects बिना ज़िम्मेदार के "open" पड़े रहते हैं, जब तक कोई customer उन्हें report न करे। Test data और scripts personal folders में रहते हैं, इसलिए अगली release regression tests शून्य से बनाती है। Temporary accounts और personal data की copies test environments में रह जाती हैं, जो security और privacy का risk है।
Tester के लिए completion काम को दिखने लायक और दोबारा इस्तेमाल लायक बनाता है। साफ़ report बताती है कि क्या टेस्ट हुआ, क्या नहीं और कौन-से risks बचे हैं, ताकि stakeholders यह जानते हुए release का फ़ैसला लें कि वे क्या स्वीकार कर रहे हैं। जो lessons learned owners वाले actions बनते हैं, उनसे टीम अगली बार समस्याएँ पहले पकड़ती है।
Test completion कब होता है
CTFL v4.0 test completion को project milestones पर रखता है: release, iteration का अंत, या system testing जैसे किसी test level का पूरा होना। Agile टीमें आम तौर पर हर sprint में हल्का completion और हर release के लिए पूरा completion करती हैं; hotfix के लिए छोटा completion काफ़ी है।
आम trigger यह है कि test plan के exit criteria का मूल्यांकन हो चुका है। Testing पहले भी रुक सकती है: समय या budget ख़त्म होने पर CTFL v4.0 testing रोकना स्वीकार्य मानता है, अगर stakeholders ने बिना और testing के go-live का risk review करके स्वीकार किया हो, और project रद्द भी हो सकता है। तब completion और भी ज़रूरी हो जाता है, क्योंकि report को साफ़ बताना होता है कि क्या नहीं किया गया। कुछ समय का ठहराव अलग बात है: वह testing का suspension है, completion नहीं।
Completion के पाँच काम
CTFL v4.0 test completion के पाँच काम (tasks) बताता है (पुराने syllabi इन्हें test closure activities कहते थे), और ISO/IEC/IEEE 29119-2 एक test completion process बताता है जिसका मूल यही है: test assets archive करना, test environment साफ़ करना, lessons learned पहचानना और report करना। हर काम एक सवाल का जवाब देता है।
- Unresolved defects — इनका क्या होगा? हर एक का owner और record किया गया फ़ैसला होता है, जो आम तौर पर product owner लेता है: बाद की release तक deferred, जिससे वह change request या product backlog item बनता है और known-issues list में जाता है; won't fix के रूप में बंद, यानी असली defect जिसे business स्वीकार करता है; या rejected, क्योंकि वह defect निकला ही नहीं।
- Testware — क्या रखने लायक है? बाद में काम आने वाले test cases, automated tests, test data और उसकी scripts, environment configuration और session notes archive या hand over होते हैं; हटाए गए features के tests retire होते हैं।
- Test environment — इसे किस स्थिति में छोड़ें? इसे owners के साथ तय स्थिति में बंद या reset करें: जानी-पहचानी baseline, hotfix testing के लिए रखा हुआ, या दूसरी टीम को सौंपा हुआ। Temporary accounts और access हटाएँ, और personal data की copies delete करें।
- Lessons learned — अगली बार क्या बदलें? विश्लेषण करें कि testing किस चीज़ से धीमी हुई, कौन-से defects देर से मिले या production तक escape हुए, और असली effort estimate के मुक़ाबले कैसा रहा। हर finding owner वाला improvement action बनती है।
- Test completion report — stakeholders को क्या जानना चाहिए? Plan के मुक़ाबले testing, deviations, fix न हुए defects, unmitigated risks, metrics और lessons learned, जो stakeholders को भेजे जाते हैं। इसकी सामग्री test reporting वाले lesson में है; completion वह समय है जब यह लिखी जाती है।
- 1Milestone पूराRelease, sprint या test level का अंत; exit criteria का मूल्यांकन, या रुकने का record किया गया फ़ैसलाTrigger
- 2Open defects पर फ़ैसलाहर एक का owner और फ़ैसला: backlog में deferred, won't fix या rejected
- 3Testware archive या hand overजो दोबारा काम आए वह रखें; पुराना retire करेंसाथ-साथ
- 4Test environment resetतय स्थिति; temporary accounts और personal data हटाए गए
- 5Lessons learned पहचानेंहर finding owner वाला action बनती है
- 6Completion report लिखें और भेजेंPlan के मुक़ाबले: deviations, open defects, residual risks
- 7HandoverKnown issues support को, smoke checks operations को, regression suite maintenance को
इसके बाद:अगले cycle में: archived testware और improvement actions उसका शुरुआती बिंदु हैं
आम क्रम: काम अक्सर एक-दूसरे पर चढ़ते हैं, और handover receiving टीमों के साथ release से पहले तय होता है।
Operations, support और maintenance को handover
CTFL v4.0 कहता है कि testware उपयुक्त टीमों को hand over किया जा सकता है। Release के बाद ये आम तौर पर operations, support और product को maintain करने वाले लोग होते हैं। Handover तब पूरा है जब receiving टीम मिली चीज़ों को tester से उनका मतलब पूछे बिना इस्तेमाल कर सके, इसलिए इसे उनके साथ release से पहले तय करें।
- Support: known-issues list — हर open defect सरल शब्दों में, किस पर असर है, workaround और backlog reference।
- Operations: post-deployment smoke checks और release के बाद देखने वाले signals, जैसे payment failure rate।
- Maintenance: नए tests और हर escaped defect के test के साथ regression suite, test data scripts और requirements से tests तक की traceability।
- सभी: completion report और archived testware कहाँ रखा है।
आज़माएँ: रिग्रेशन सिनेरियो जनरेटर आज़माएँ: Requirements → टेस्ट केस
Worked example: checkout की release 3.4 बंद करना
एक food-delivery app version 3.4 release करता है: wallet payments जुड़ते हैं, नई coupon screen पुरानी की जगह लेती है और cash on delivery हटाया जाता है। Exit criteria: हर high-risk requirement टेस्ट हो, कोई open Blocker या Critical defect न हो, regression suite pass हो। 192 planned test cases में से 186 execute हुए; product owner ने wallet के 6 low-risk cases को descope किया क्योंकि wallet provider का sandbox दो दिन बंद रहा, इसलिए high-risk वाला criterion फिर भी पूरा रहा।
नीचे के record में दो बातें देखें: descope हुए 6 cases deviation के रूप में अपने residual risk के साथ दिखते हैं, जिसे product owner ने लिखित में स्वीकार किया, और हर line का एक owner या destination है।
Test completion record: release 3.4 (checkout)
Trigger: exit criteria के मूल्यांकन के बाद go decision
Execution: 192 में से 186 test cases; wallet के 6 low-risk cases descoped
(wallet sandbox 2 दिन बंद), residual risk product owner ने लिखित में स्वीकार किया
Defects:
- DEF-481 (Major) Coupon दोबारा लगाने पर discount दो बार दिखता है;
PB-902 में गया, workaround: coupon हटाकर फिर से लगाएँ
- DEF-487 (Minor) Receipt e-mail में date गलत format में; PB-903 में गया
Testware:
- 38 नए API tests regression suite में merge हुए
- Test data script को release-3.4 tag करके archive किया
- Cash-on-delivery के 6 tests retire (feature हटाया गया)
Environment: staging baseline पर reset; 4 temporary admin accounts हटाए
Lessons learned:
- Sandbox outage से 2 दिन गए; action: test plan में sandbox book करें
(owner: QA lead)
- DEF-455 release 3.3 से escape हुआ; action: regression test जोड़ा (owner: tester)
Report: product owner, development lead और support lead को भेजी
Handover:
- Support: known issues DEF-481 और DEF-487, workaround के साथ
- Operations: smoke checks; 48 घंटे payment failure rate पर नज़रआम गलतियाँ
- Release निकलने और अगला sprint शुरू होने की वजह से completion छोड़ देना।
- Unfixed defects को बिना फ़ैसले और बिना owner के open छोड़ना।
- सब कुछ archive करना, obsolete tests समेत, ताकि कोई archive दोबारा इस्तेमाल न कर पाए — या personal folders के बाहर कुछ भी archive न करना।
- Lessons learned को शिकायतों की तरह लिखना ("environment ख़राब था"), बिना action, owner और तारीख़ के।
- Test environment में temporary accounts, access rights और personal data की copies छोड़ देना।
- आख़िरी दिन एक link भेजकर handover करना, बिना यह तय किए कि receiving टीम को क्या चाहिए।
QA का नज़रिया
Completion छोटा और routine होता है, जब उसकी planning की गई हो। इसके कामों को test plan और release checklist में रखें ताकि उनके लिए समय तय रहे, और known-issues list व handover notes execution के दौरान ही शुरू करें, जब details ताज़ा हों।
Defect के फ़ैसलों पर product owner के साथ, environment और regression suite पर development lead और DevOps engineer के साथ, और handover पर support व operations के साथ काम करें। हर फ़ैसला नाम और तारीख़ के साथ record करें — "product owner ने DEF-481 open रहते release स्वीकार की" — और report वहाँ रखें जहाँ अगला tester सबसे पहले देखेगा। Lessons learned की चर्चा में पूछें: हमें क्या करते रहना चाहिए, किस चीज़ ने हमें धीमा किया, और कौन-से defects हमें पहले पकड़ने चाहिए थे?
अभ्यास
एक sprint की testing बंद करें
आपकी टीम ने एक online pharmacy app का sprint 14 पूरा किया है; स्थिति नीचे है। इस sprint का test completion लिखें, इसमें यह भी कि completion report न चले tests के बारे में क्या कहेगी।
Sprint 14: prescription upload
Planned test cases: 64; executed: 60; not run: 4
(हाथ से लिखे prescriptions की पहचान: OCR service तैयार नहीं थी)
Open defects:
- DEF-210 (Major) 8 MB से बड़ी PDF files का upload fail होता है
- DEF-214 (Minor) Order history में Arabic file names प्रश्नचिह्न बनकर दिखते हैं
- DEF-219 (Trivial) छोटी screens पर upload button का icon खिसका हुआ है
New testware: 22 manual test cases, 9 automated API tests,
12 sample prescription files (इनमें 3 असली prescriptions के scans हैं)
Environment: shared staging; testing के लिए 3 temporary pharmacist accounts बने
Notes: OCR service के इंतज़ार में 1.5 दिन गए;
sprint 13 का DEF-201 release के बाद एक customer ने report किया- तय करें कि हर open defect का क्या होगा और फ़ैसला कौन करेगा।
- रखने, archive करने या retire करने वाला testware लिखें।
- Environment की अंतिम स्थिति लिखें।
- दो lessons learned लिखें, हर एक के action और owner के साथ।
- बताएँ कि handover में किसे क्या मिलेगा और report न चले 4 tests के बारे में क्या कहेगी।
मॉडल उत्तर दिखाएँ
Defects: DEF-210 (Major) product owner के prioritise करने के लिए backlog item बनता है; fix होने तक support users को workaround देता है: "8 MB से छोटी files upload करें"। DEF-214 (Minor) और DEF-219 (Trivial) backlog items बनते हैं, या product owner DEF-219 को won't fix के रूप में बंद करके उसका कारण record करता है।
Testware: 22 manual test cases रखें, 9 API tests और escape हुए DEF-201 का test regression suite में जोड़ें, और 4 OCR cases को चलाने के लिए तैयार रूप में archive करें। असली prescriptions के 3 scans की जगह synthetic files रखें और scans delete करें: personal health data archive नहीं होना चाहिए।
Environment: 3 temporary pharmacist accounts हटाएँ, असली prescriptions के scans की upload हुई सभी copies delete करें और shared staging को उसकी तय baseline पर छोड़ें।
Lessons learned: "OCR के इंतज़ार में 1.5 दिन गए" → sprint planning में third-party services की उपलब्धता पक्की करें (owner: QA lead)। "DEF-201 escape हुआ" → छूटी हुई test condition खोजकर जोड़ें (owner: tester)।
Handover और report: support को known-issues list मिलती है, जिसमें हर open defect सरल शब्दों में और DEF-210 का workaround है; developers को updated regression suite मिलती है। Report न चले 4 tests को deviation के रूप में लिखती है: हाथ से लिखे prescriptions की पहचान untested है, इसलिए report सिफ़ारिश करती है कि टेस्ट होने तक इसे release से बाहर रखा जाए; अगर product owner लिखित में यह risk स्वीकार करता है, तो वह फ़ैसला report में record होता है।
अक्सर पूछे जाने वाले सवाल
क्या test completion और test closure एक ही हैं?
व्यवहार में हाँ। "Test closure" और "test cycle closure" इसी काम के पुराने या industry नाम हैं; ISTQB CTFL v4.0 इसे test completion कहता है। इसका मुख्य output test completion report है, जिसे पुरानी सामग्री test summary report कहती है और ISO/IEC/IEEE 29119-3 test management documents में से एक के रूप में परिभाषित करता है।
क्या agile टीमें test completion करती हैं?
हाँ, लेकिन छोटे और ज़्यादा बार होने वाले कदमों में। Sprint के अंत में यह ज़्यादातर unresolved defects को product backlog में ले जाना, regression suite को current रखना और Sprint Retrospective में हिस्सा लेना है, जहाँ Scrum Team quality और effectiveness बढ़ाने के तरीके plan करती है। Release पर टीम completion report, handover और environment clean-up जोड़ती है। काम वही रहते हैं; पैमाना बदलता है।
अगर exit criteria पूरे होने से पहले testing रुक जाए तो?
फिर भी completion करें। Completion report बताती है कि कौन-से exit criteria पूरे नहीं हुए, कौन-से tests नहीं चले और कितना risk बचा है, और जो stakeholders वह risk स्वीकार करते हैं वे अपना फ़ैसला record करते हैं। Tester जानकारी देता है और सिफ़ारिश करता है; release का फ़ैसला stakeholders का होता है।
संदर्भ
- ISTQB Certified Tester Foundation Level (CTFL) v4.0सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
- ISO/IEC/IEEE 29119-2:2021 — Software and systems engineering — Software testing — Part 2: Test processesटेस्ट प्रक्रिया मॉडल: संगठनात्मक, टेस्ट प्रबंधन और dynamic टेस्ट प्रक्रियाएँ, उनकी गतिविधियों और परिणामों के साथ।
- ISO/IEC/IEEE 29119-3:2021 — Software and systems engineering — Software testing — Part 3: Test documentationटेस्ट दस्तावेज़ों के टेम्पलेट और सामग्री — test policy, strategy, plan, status व completion रिपोर्ट, incident रिपोर्ट।
- The 2020 Scrum GuideScrum की परिभाषा: उसकी ज़िम्मेदारियाँ, events और artifacts, Definition of Done सहित जिसे पूरा करने में टेस्टिंग मदद करती है।
Mutqan tools से अभ्यास करें
क्रमांकित आवश्यकताओं की सूची को requirement-to-test मैट्रिक्स के साथ ट्रेस करने योग्य टेस्ट केस में बदलें।
बदलाव के विवरण और प्रभावित तथा संबंधित मॉड्यूल की सूची से रिग्रेशन सिनेरियो जनरेट करें।
Markdown (.md) फ़ाइलों को ब्राउज़र में PDF में बदलें: शीर्षक, सूचियाँ, तालिकाएँ, कोड ब्लॉक, उद्धरण, लिंक और चित्र एम्बेडेड फ़ॉन्ट से टाइपसेट।
Mutqan AI से requirements या किसी user story की तुलना मौजूदा टेस्ट केस से करके अनटेस्टेड हिस्से खोजें।
और गहराई से
इस topic में आपकी प्रगति
प्रगति ट्रैक करने के लिए साइन इन करें
Topics पूर्ण चिह्नित करें, जहाँ छोड़ा था वहीं से जारी रखें और specialisation परीक्षाएँ खोलें।