रिलीज़ रेडीनेस और Go/No-Go फ़ैसला
Release readiness वह स्थिति है जिसमें कोई release अपने users तक ऐसे risks के साथ पहुँच सके जिन्हें ज़िम्मेदार लोग जानते हैं और स्वीकार कर चुके हैं। इसे परखने के लिए सिर्फ़ testing से ज़्यादा evidence चाहिए: क्या product काम करता है, क्या उसे deploy, monitor और rollback किया जा सकता है, क्या support users की मदद कर सकता है, और क्या business launch के लिए तैयार है? कोई release हर test pass करके भी ready न हो, यह मुमकिन है: booking app का नया payment feature सारे tests pass कर सकता है, जबकि उसके database change का rollback कभी आज़माया ही नहीं गया।
Go/no-go decision वह पल है जब यह evidence review होता है और नाम से तय decision owner चुनता है: go, no-go, या conditional go, जिसमें release तभी आगे बढ़ती है जब तय conditions पूरी होती रहें। Quality gates वाले lesson का release gate कई teams go/no-go meeting के रूप में चलाती हैं, और पिछले lesson में बताई गई test completion report और residual-risk statement उसके मुख्य inputs होते हैं। ISTQB Foundation syllabus इस meeting को परिभाषित नहीं करता; यह industry practice है, जिसे release readiness review भी कहते हैं।
यह क्यों ज़रूरी है
Releases ऐसे कारणों से fail होती हैं जिन्हें कोई test case check नहीं करता: data migration जिसे undo नहीं किया जा सकता, alert जिसे किसी ने configure नहीं किया, support desk जिसे बदली हुई screen का पता नाराज़ customers से चलता है। Readiness review users से पहले ये सवाल पूछता है, और "क्या हम ready हैं?" को अंदाज़े की जगह ऐसा decision बनाता है जिसके criteria, evidence और owner हों।
Tester के लिए यहीं उसका काम इस्तेमाल होता है। ISTQB Foundation syllabus testing के objectives में stakeholders को informed decisions के लिए जानकारी देना गिनाता है। जो tester "QA approves" जैसे गोलमोल वाक्य की जगह evidence और residual risk साफ़ रखता है, वह भरोसा कमाता है, और recorded decision दिखाता है कि किस risk को किसने स्वीकार किया।
Readiness सिर्फ़ test results नहीं है
Readiness checklist criteria को areas में बाँटती है, और हर area का एक lead उसका जवाब देता है। नाम बदलते रहते हैं, और कुछ organisations अलग operational readiness review करती हैं, लेकिन ज़्यादातर checklists चार areas कवर करती हैं, और हर criterion वह evidence बताता है जिससे उसे पढ़ा जाता है:
- Product: test exit criteria पूरे; कोई open blocker या critical defect नहीं; known issues का workaround मौजूद; non-functional targets पूरे। Evidence: test report और defect tracker।
- Operations: deployment और rollback steps लिखे हुए और rehearse किए हुए; data migrations reversible हैं या recovery plan से कवर हैं; monitoring और alerts नए हिस्सों को कवर करते हैं; कोई on-call है। Evidence: rehearsal record और dashboards।
- Support: team को briefing मिल चुकी है, उसके पास workarounds वाला known-issues note है और उसे पता है कि escalate कहाँ करना है। Evidence: published note।
- Business: release notes और user messages approved; legal या contractual approvals मौजूद; partners और providers ready। Evidence: approvals।
Quality gates से go/no-go meeting तक
Quality gates वाला lesson याद करें: gate तय point पर agreed criteria check करता है, और release gate का owner एक व्यक्ति होता है जो decide करता है। Go/no-go meeting पहले के gates दोहराती नहीं, उनके results पढ़ती है; वह ऐसा evidence जोड़ती है जो pipeline नहीं बना सकती, यानी operations, support और business से, और बचे हुए risk पर judgement।
Checklist लिखते समय हर criterion को must-have या should-have mark करें, meeting में नहीं। अधूरा must-have मतलब no-go, जब तक decision owner साफ़ तौर पर conditional go स्वीकार न करे; अधूरा should-have एक risk के रूप में report होता है, जिसे owner स्वीकार कर सकता है।
Meeting release से एक-दो दिन पहले रखें, और जो open रह गया हो उसके लिए deployment से ठीक पहले एक छोटा final check। Decision owner, अक्सर product owner या release manager, meeting chair करता है और decide करता है; QA, engineering, operations और support के leads शामिल होते हैं। सबको checklist, test completion report और residual-risk statement पहले मिलते हैं: meeting में surprise का मतलब है कि reporting fail हुई।
Go/no-go meeting, release 2.8 (30 मिनट)
Decision owner: product owner
24 घंटे पहले भेजे गए inputs: checklist, test completion report,
residual-risk statement, open defects
1. Scope: क्या शामिल है, plan के बाद क्या हटाया गया
2. Criteria: हर एक का status और evidence link, must-haves पहले
3. Open defects और risks: users पर असर, workaround, mitigation
4. Area leads (product, operations, support, business): ready या नहीं
5. Decision: go, conditional go या no-go, owner खुद घोषित करे
6. Record और भेजना: decision, conditions, owners, deadlines, fallbacksआज़माएँ: Markdown फ़ॉर्मेटर आज़माएँ: रिस्क-बेस्ड टेस्ट जनरेटर
Go, no-go और conditional go
Go का मतलब है कि हर must-have पूरा है और decision owner जाने-पहचाने residual risks स्वीकार करता है। No-go का मतलब है कि कोई must-have पूरा नहीं और समय रहते उसे contain नहीं किया जा सकता; यह नाकामी नहीं, एक decision है, जो बताता है कि क्या बदलना है और team दोबारा कब decide करेगी।
Conditional go का मतलब है कि release तभी आगे बढ़ती है जब नाम से तय conditions पूरी हों। Condition deployment से पहले लागू हो सकती है; rollout के दौरान, जब release पहले एक region या canary तक पहुँचती है और agreed signals ठीक रहने पर ही आगे फैलती है (Google की The Site Reliability Workbook canarying को किसी change का partial, time-limited deployment और उसका evaluation बताती है); या release के बाद, जैसे किसी known issue का तय तारीख़ तक fix। "Go करो, बाद में ठीक कर लेंगे" condition नहीं है। असली condition के पाँच हिस्से होते हैं:
- Check करने लायक result: "staging पर rollback rehearsal pass", न कि "rollback ठीक लगता है"।
- एक owner जो condition पूरी होने पर report करे।
- Deadline या trigger: deployment से पहले, rollout का कोई step, या कोई तारीख़।
- पूरी न हो तो fallback: no-go, rollout रोकना, rollback, या feature flag बंद करना।
- Condition open रहने तक बचे risk की decision owner द्वारा recorded स्वीकृति।
उत्तर: हाँ
परिणाम: GoDecision owner जाने-पहचाने residual risks स्वीकार करता है। Decision record करें और plan के मुताबिक deploy करें।पासउत्तर: नहीं
प्रश्न 2: क्या हर gap को किसी condition से contain किया जा सकता है?Check करने लायक result, जिसका owner, deadline और पूरा न होने पर fallback हो।उत्तर: नहीं
परिणाम: No-goलिखें कि क्या बदलना है, उसका owner कौन है और team दोबारा कब decide करेगी।फ़ेलउत्तर: हाँ
प्रश्न 3: क्या decision owner conditions open रहने तक बचा risk स्वीकार करता है?उत्तर: नहीं
परिणाम: अभी no-goTeam scope घटा सकती है या और evidence जुटा सकती है, फिर दोबारा decide करे।फ़ेलउत्तर: हाँ
परिणाम: Conditional goहर condition उसके owner, deadline और fallback के साथ record करें; हर condition को पूरी होने या उसका fallback लागू होने तक track करें।सावधानी
हर सवाल का जवाब नाम से तय decision owner देता है; QA lead और बाकी area leads evidence लाते हैं।
Worked example: release 2.8 का go/no-go
Clinic appointments बुक करने वाला एक web app release 2.8 गुरुवार 22:00 बजे के लिए plan करता है: bookings के लिए online deposits (नया, एक feature flag के पीछे जिसे हर clinic के लिए अलग से on किया जा सकता है) और 14 fixes। बुधवार की go/no-go meeting में QA lead बताता है: 286 में से 286 regression tests pass, scope के हर acceptance criterion का passing test है, और कोई open blocker या critical defect नहीं। एक major defect open है: DEF-417, Arabic में की गई bookings के receipt email में clinic का address नहीं आता।
दो gaps बाकी हैं: payments table जोड़ने वाले database change का rollback rehearse नहीं हुआ, जो must-have है; और support की briefing गुरुवार 09:00 बजे तय है। QA lead एक residual risk जोड़ता है: payments provider के test environment पर टेस्ट हुए, और production account कल ही activate हुआ। Product owner decide करता है: conditional go।
- C1, deployment से पहले: staging पर rollback rehearsal गुरुवार 16:00 तक pass हो। Owner: engineering lead। वरना: no-go, अगली window रविवार।
- C2, deployment से पहले: support को briefing और DEF-417 का known-issue note published। Owner: support lead। वरना: deposits बंद रहेंगे।
- C3, rollout के दौरान: deposits एक clinic के लिए on होंगे और QA lead production में एक छोटा असली payment और उसका refund करेगा; बाकी clinics अगली सुबह तभी जुड़ेंगी जब provider रात भर में कोई failed या duplicate charge न दिखाए। Owner: QA lead और on-call engineer। वरना: flag off, और bookings deposits के बिना चलती रहेंगी।
- C4, release के बाद: DEF-417 सात दिन में release 2.8.1 में ठीक हो। Owner: engineering lead। वरना: product owner accepted risk की दोबारा समीक्षा करता है, और fix ship होने तक known-issue note published रहता है। Accepted risk: कुछ Arabic receipt emails में address नहीं होगा।
- Final check, गुरुवार 17:00: C1 और C2 evidence links के साथ पूरे, product owner go confirm करता है, और decision record सभी stakeholders को जाता है।
आम गलतियाँ
- Readiness को "सारे tests pass" मान लेना और rollback, monitoring, support या approvals के बारे में कभी न पूछना।
- कौन-से criteria must-have हैं, यह meeting के दौरान deadline के दबाव में तय करना।
- पहले से भेजा गया evidence review करने की जगह meeting में problems खोजना।
- बिना owner, deadline या fallback की conditions, जो conditional go को चुपचाप सामान्य go बना देती हैं।
- Tester का अकेले quality sign-off करना: tester evidence और recommendation देता है, decision owner decide करता है।
- Decision, accepted risks और conditions पूरी हुईं या नहीं, इसका कोई written record न होना।
QA का नज़रिया
Readiness का काम release plan होते समय शुरू करें: बाकी leads के साथ checklist propose करें, must-haves mark करें और तय करें कि decide कौन करेगा। Testing के दौरान product वाला हिस्सा अपडेट रखें, ताकि checklist और आपकी test reports एक ही कहानी कहें।
Meeting में evidence और user impact की भाषा में बोलें, साफ़ recommendation दें (go, इन conditions के साथ conditional go, या no-go) और बताएँ कि वह किस बात से बदलेगी। Conditional go के बाद conditions को test cases की तरह track करें और हर condition के पूरे होने या चूकने की report दें। समय के साथ decisions की तुलना नतीजों से करें: DORA का change fail rate, यानी उन deployments का हिस्सा जिन्हें rollback या hotfix जैसे तुरंत हस्तक्षेप की ज़रूरत पड़ी, दिखाता है कि आपके go decisions टिकते हैं या नहीं।
अभ्यास
School-fees portal की release 4.1 पर फ़ैसला करें
आप मंगलवार की go/no-go meeting में QA lead हैं; school-fees portal की release 4.1 गुरुवार 21:00 बजे के लिए planned है। यह fees के instalment plans जोड़ती है, जिनका कोई feature flag नहीं, और नौ fixes। Checklist नीचे है। Engineering manager सुझाव देता है: "Go करते हैं, DEF-905 अगले sprint में ठीक कर देंगे।"
एक decision recommend करें और वह record लिखें जिसे product owner approve कर सके।
Release 4.1, school-fees portal, planned: गुरुवार 21:00
Must-haves: कोई open blocker/critical defect नहीं; rollback rehearsed;
नए components के लिए alerts
Should-haves: बाकी सभी items
Product Regression: 520 में से 518 pass; 2 failures: DEF-905, DEF-902
Product DEF-905 (critical): fee 3 से विभाजित न हो तो instalments का total
fee से 1 SAR ज़्यादा; finance ने rounding rule अभी confirm नहीं
किया (meeting बुधवार 10:00)
Product DEF-902 (minor): Arabic PDF receipts पर logo ग़लत जगह; text सही
Product Payment API p95: expected peak पर 610 ms (target: अधिकतम 800 ms)
Operations Staging पर rollback rehearsal: pass, 12 मिनट
Operations नए instalment scheduler के alerts: configure नहीं हुए
Support Team को briefing मिली; parents का FAQ: draft, approval बाकी
Business Instalments की घोषणा वाला parents को email: approved, शुक्रवार को- Items को पूरे और अधूरे में बाँटें, और अधूरे must-haves mark करें।
- Engineering manager के सुझाव को condition के पाँच हिस्सों पर परखें।
- Go, conditional go या no-go चुनें और evidence के साथ कारण बताएँ।
- हर condition उसके owner, deadline और fallback के साथ लिखें, फिर accepted risks।
मॉडल उत्तर दिखाएँ
अधूरे: DEF-905 (must-have: कोई open blocker या critical defect नहीं), scheduler alerts (must-have: नए components के लिए alerts) और parents वाला FAQ (should-have)। दोनों regression failures DEF-905 और DEF-902 हैं; DEF-902 minor है, इसलिए कोई must-have उसे कवर नहीं करता। बाकी सब पूरा है: rollback rehearsal pass हुआ, और payment API का p95 अधिकतम 800 ms के मुक़ाबले 610 ms है।
यह सुझाव condition नहीं है। पाँच हिस्सों पर परखें तो इसमें users पर असर से पहले check करने लायक कोई result नहीं, कोई नामित owner नहीं, कोई पक्की deadline नहीं ("अगला sprint" अस्पष्ट है), कोई fallback नहीं और risk की कोई recorded स्वीकृति नहीं। Feature flag न होने से defect को कोई चीज़ contain नहीं करती: गुरुवार रात से जो parents ऐसी fee के लिए instalments चुनेंगे जो 3 से विभाजित नहीं होती, वे 1 SAR ज़्यादा देंगे। इसे स्वीकार करना product owner का record पर लिया गया फ़ैसला होगा, और आप इसके ख़िलाफ़ recommend करते हैं।
गुरुवार 16:00 पर final check के साथ conditional go recommend करें। C1: finance बुधवार को rounding rule confirm करे, और DEF-905 ठीक होकर गुरुवार 15:00 तक confirmation testing और regression re-run pass करे (owner: engineering lead)। C2: scheduler alerts configure हों और गुरुवार 15:00 तक एक test alert मिल जाए (owner: on-call engineer)। कोई भी चूके तो: no-go, अगली window रविवार 21:00, और parents को शुक्रवार वाला email टाल दिया जाए।
C3: शुक्रवार के email से पहले parent FAQ approve हो (owner: support lead); वरना support अपनी briefing के आधार पर जवाब दे। Accepted risk, product owner की approval के साथ recorded: DEF-902, जिसका fix 4.1.1 में होगा।
अक्सर पूछे जाने वाले सवाल
Go/no-go decision कौन लेता है?
पहले से तय, नाम वाला decision owner, आम तौर पर product owner, release manager या business owner, क्योंकि business risk की जवाबदेही उसी की है। QA, engineering, operations और support के leads evidence और recommendations देते हैं। अगर meeting से पहले किसी का नाम तय नहीं, तो सबसे पहले वही तय करें।
क्या conditional go और gate exception एक ही हैं?
नहीं, हालाँकि दोनों अक्सर साथ आते हैं। Exception, जैसा quality gates वाले lesson में देखा, एक criterion को recorded कारण और expiry के साथ छोड़ता है। Conditional go ऐसा decision है जो meeting के बाद होने वाली बातों पर टिका है: अगर कोई condition अपनी deadline तक पूरी न हो, तो agreed fallback लागू होता है, जैसे no-go या feature flag बंद करना।
जो teams दिन में कई बार deploy करती हैं, क्या वे भी go/no-go meetings करती हैं?
आम तौर पर हर change के लिए नहीं। Continuous deployment में readiness criteria automated pipeline gates, feature flags और progressive rollouts में बने होते हैं, और हर change छोटा होता है। फिर भी ज़्यादा business risk वाले changes के लिए meeting आम है, जैसे marketing date से जुड़ा launch, regulatory change, data migration या नया payment provider।
अगर decision owner मेरी recommendation के ख़िलाफ़ go चुने तो?
अगर उसने evidence देखा है तो यह फ़ैसला उसका है। पक्का करें कि record में आपकी recommendation, user impact की भाषा में risk और उसे स्वीकार करने वाले का नाम हो, फिर monitoring, support के लिए workaround और fix की तारीख़ से risk घटाने में मदद करें। Escalate सिर्फ़ तब करें जब evidence ग़लत तरीके से पेश हुआ हो या कोई must-have बिना record के छोड़ा गया हो।
संदर्भ
- ISTQB Certified Tester Foundation Level (CTFL) v4.0सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
- Canarying Releases — The Site Reliability Workbookबदलाव को पहले ट्रैफ़िक के छोटे हिस्से पर रिलीज़ करना और पूरी तरह फैलाने से पहले baseline से तुलना करना — SRE में deployment verification।
- DORA's software delivery performance metricsDORA के डिलीवरी मेट्रिक्स — change lead time, deployment frequency, failed deployment recovery time, change fail rate आदि — throughput और instability में समूहित।
Mutqan tools से अभ्यास करें
फ़ीचर को संभावना और प्रभाव के आधार पर स्कोर दें, फिर प्राथमिकता वाला risk-based टेस्ट प्लान जनरेट करें।
conditions और actions से decision table बनाएँ, सभी rule संयोजन जनरेट करें और असंभव संयोजनों को समेट दें।
एक साथ कई API health endpoint जाँचें और स्टेटस, latency तथा pass/fail सारांश पाएँ।
Markdown की फ़ॉर्मेटिंग (हेडिंग, सूचियाँ, टेबल, emphasis) सामान्य करें और रेंडर किया नतीजा देखें।
Markdown (.md) फ़ाइलों को ब्राउज़र में PDF में बदलें: शीर्षक, सूचियाँ, तालिकाएँ, कोड ब्लॉक, उद्धरण, लिंक और चित्र एम्बेडेड फ़ॉन्ट से टाइपसेट।
और गहराई से
इस topic में आपकी प्रगति
प्रगति ट्रैक करने के लिए साइन इन करें
Topics पूर्ण चिह्नित करें, जहाँ छोड़ा था वहीं से जारी रखें और specialisation परीक्षाएँ खोलें।