टेस्ट मेट्रिक्स जो फ़ैसले तय करें
कोई test metric तभी इकट्ठा करने लायक है जब उसकी वजह से कोई अलग फ़ैसला ले: रिलीज़ करें या रुकें, किसी हिस्से में tester बढ़ाएँ, pipeline ठीक करें, requirements लिखने का तरीका बदलें। जिन संख्याओं पर कोई कार्रवाई नहीं करता वे सजावट हैं, और उन्हें जुटाने में समय और पढ़ने में ध्यान ख़र्च होता है।
यह गाइड वे metrics समझाती है जो QA टीमें सच में इस्तेमाल करती हैं — coverage, execution, defect और delivery metrics — उनके फ़ॉर्मूले, हर एक क्या बता सकता है और क्या नहीं, अलग-अलग audience को इन्हें कैसे रिपोर्ट करें, और इनका दुरुपयोग कैसे होता है। अंत में एक पेज की sample status report और लोकप्रिय vanity संख्याओं की जगह क्या मापें, उसकी सूची है।
Dashboard से नहीं, फ़ैसले से शुरू करें
ISTQB syllabus metrics को test monitoring और control का हिस्सा मानते हैं: आप plan के मुक़ाबले progress और quality मापते हैं ताकि दिशा सुधार सकें। Metrics चुनने का व्यावहारिक तरीका Goal–Question–Metric approach है: पहले goal लिखें (checkout को बिना किसी ज्ञात payment defect के रिलीज़ करना), फिर वे सवाल जो बताएँ कि आप वहाँ पहुँच रहे हैं या नहीं (कौन-से payment risk अभी टेस्ट नहीं हुए? क्या defect उतनी तेज़ी से ठीक हो रहे हैं जितनी तेज़ी से मिल रहे हैं?), और उसके बाद ही वे metrics जो इन सवालों का जवाब दें।
- हर metric का एक owner हो, लिखित परिभाषा हो (क्या गिना जाता है, क्या नहीं, किस सिस्टम से) और एक फ़ैसला हो जिसमें वह काम आए।
- Snapshot की जगह trend चुनें: 82% pass rate ज़्यादा कुछ नहीं बताता; तीन दिनों में 64% → 75% → 82% बहुत कुछ बताता है।
- हर metric के साथ एक counter-metric रखें ताकि एक को धोखे से सुधारना दूसरे में दिख जाए (executed tests के साथ escaped defects; speed के साथ change fail rate)।
- सेट छोटा रखें। पाँच metrics जिन्हें लोग पढ़ते हैं, तीस से बेहतर हैं जिन्हें कोई नहीं पढ़ता।
Coverage metrics
Coverage इस सवाल का जवाब देता है: "जो मायने रखता है उसका कितना हिस्सा हमने चलाया?" उपयोगी सवाल हमेशा यह है कि coverage किसका: requirements, risks या code। हर एक का owner अलग है और blind spot भी अलग।
- Requirements / acceptance-criteria coverage = कम से कम एक passing test वाले criteria ÷ कुल criteria। "test है" और "passing test है" में फ़र्क़ करें; रिलीज़ के समय सिर्फ़ दूसरे का मतलब है। इसके लिए traceability चाहिए: हर test उस criterion से लिंक हो जिसे वह जाँचता है।
- Risk coverage = पहचाने गए वे risks जिनके planned tests चलकर pass हुए ÷ पहचाने गए risks, risk level के हिसाब से रिपोर्ट किया हुआ। "सभी 9 Very high risk कवर, 12 में से 4 Medium अभी नहीं" रिलीज़ की बातचीत है; "85% tests pass हुए" नहीं।
- Code coverage — tests चलते समय tool द्वारा मापा गया statement (line) या branch coverage। यह ऐसे code खोजने में उपयोगी है जिसे कोई test नहीं छूता। यह नहीं दिखाता कि tests कुछ जाँचते भी हैं: बिना assertion वाला test हर line चला सकता है। ऊँचा line coverage अच्छे tests का सबूत नहीं है; लेकिन critical module में कम coverage gap का सबूत ज़रूर है।
- Test की ताक़त जाँचना — जहाँ code coverage को quality signal माना जाता है, वहाँ assertions की review या mutation testing (जानबूझकर code बदलना और देखना कि कोई test फ़ेल होता है) दिखाता है कि कवर हुआ code सच में verify होता है या नहीं।
आज़माएँ: AI टेस्ट कवरेज एनालाइज़र आज़माएँ: Requirements → टेस्ट केस आज़माएँ: Requirements → टेस्ट सिनेरियो
Execution metrics
Execution metrics दिखाते हैं कि test effort plan के मुक़ाबले कहाँ खड़ा है। इन्हें सिर्फ़ एक total के रूप में नहीं, risk level या feature area के हिसाब से रिपोर्ट करें, क्योंकि 90% executed यह छिपा सकता है कि बचा हुआ 10% payment flow है।
- Planned बनाम executed बनाम passed — progress की बुनियादी तस्वीर। Executed = passed + failed; blocked और not-run tests अलग से रिपोर्ट होते हैं।
- Pass rate = passed ÷ executed। Builds के साथ इसका trend देखें; cycle के आख़िर में गिरता pass rate आमतौर पर fixes से आए regressions का संकेत है।
- Blocked tests — वे tests जो environment, data या dependency की समस्या के कारण नहीं चल सकते। ये project-risk का संकेत हैं और इन्हें सिर्फ़ गिनती नहीं, owner और तारीख़ चाहिए।
- Re-runs और flaky नतीजे — अगर कोई test सिर्फ़ retry पर pass होता है तो उसे अलग गिनें। Retry किए गए flaky tests समेत pass rate stability को बढ़ा-चढ़ाकर दिखाता है।
- Automated suite health — CI में regression suite की अवधि और flaky rate, क्योंकि धीमा या अविश्वसनीय suite चलाना लोग बंद कर देते हैं।
Defect metrics
Defect metrics प्रोडक्ट और उसे बनाने वाली process दोनों का वर्णन करते हैं। ये गिनती के एक जैसे नियमों पर निर्भर करते हैं — defect किसे माना जाए, कौन-सी severity गिनी जाए, गिनती की window कब बंद हो — इसलिए कोई भी दो संख्याएँ मिलाने से पहले ये नियम लिख लें।
- Defect density = defects ÷ size (प्रति हज़ार lines of code, प्रति function point, प्रति story)। सावधानियाँ: size के माप भाषाओं और टीमों में अलग होते हैं, गिनती से ज़्यादा severity mix मायने रखता है, और ऊँची density अच्छी testing भी दिखा सकती है और ख़राब code भी। किसी component की तुलना उसके अपने इतिहास से करें, दूसरी टीमों से नहीं।
- Defect detection percentage (DDP) = रिलीज़ से पहले मिले defects ÷ (रिलीज़ से पहले मिले + तय window में रिलीज़ के बाद मिले) × 100। उदाहरण के लिए, testing में 45 और रिलीज़ के बाद पहले 30 दिनों में 5 रिपोर्ट हुए तो DDP = 45 ÷ 50 = 90%।
- Escape rate (defect leakage) = इसका पूरक: 5 ÷ 50 = 10% escaped। Leakage को phase के हिसाब से भी ट्रैक किया जा सकता है — वे defects जो system testing से निकल गए और acceptance testing में मिले।
- Defect age — रिपोर्ट से closure (या fix verification) तक का समय। Median और severity के हिसाब से सबसे पुराने खुले items रिपोर्ट करें; कुछ बहुत पुराने defects औसत को बिगाड़ देते हैं।
- Reopen rate = reopen हुए defects ÷ उस अवधि में resolve हुए defects। उदाहरण के लिए, 80 में से 6 = 7.5%। बढ़ती दर अधूरे fixes, अस्पष्ट रिपोर्ट या कमज़ोर retesting की ओर इशारा करती है।
- Severity के हिसाब से defects — समय के साथ हर severity के खुले और मिले defects; रिलीज़ का सवाल आमतौर पर यह होता है: "कितने Blocker और Critical defects खुले हैं?", और जवाब शून्य या स्पष्ट रूप से स्वीकार किया हुआ होना चाहिए।
- Root cause के हिसाब से defects — requirements, design, code, configuration, data, environment। यही metric process को सुधारता है: अगर एक-तिहाई defects अस्पष्ट requirements से आते हैं, तो ज़्यादा testing इसे ठीक नहीं करेगी; requirement reviews करेंगे।
Flow और delivery metrics: DORA metrics
DORA (DevOps Research and Assessment) software delivery performance को पाँच metrics से बताता है, जिन्हें वह throughput (change lead time, deployment frequency, failed deployment recovery time) और instability (change fail rate, deployment rework rate) में बाँटता है; यह मॉडल मूल चार keys से विकसित हुआ है। ये पूरे delivery system को मापते हैं, test टीम को नहीं, लेकिन testing इन पर गहरा असर डालती है: तेज़ और भरोसेमंद automated tests बार-बार deployment को सुरक्षित बनाते हैं, और कमज़ोर tests failed deployments के रूप में दिखते हैं।
- Change lead time — किसी बदलाव को version control में commit होने से production में deploy होने तक लगने वाला समय।
- Deployment frequency — बदलाव कितनी बार production में deploy होते हैं।
- Failed deployment recovery time — ऐसे फ़ेल deployment से recover करने में लगने वाला समय जिसमें तुरंत दख़ल चाहिए।
- Change fail rate — उन deployments का अनुपात जिनके बाद तुरंत दख़ल चाहिए, जैसे rollback या hotfix।
- Deployment rework rate — उन unplanned deployments का अनुपात जो production incident की वजह से किए जाते हैं। इनमें से कोई भी अपनाने से पहले DORA साइट पर परिभाषाएँ पढ़ें, और कहीं और से benchmark संख्याएँ उधार न लें; अपने trend की तुलना करें।
- Testing के नज़रिए से: change fail rate, defect escape rate का delivery-स्तर का रिश्तेदार है; suite की अवधि change lead time का बड़ा हिस्सा है।
Reporting और dashboards
दो तरह की रिपोर्ट ज़्यादातर ज़रूरतें पूरी करती हैं। CTFL syllabus इन्हें test progress report कहता है, जो testing के दौरान नियमित रूप से बनती है, और test completion report, जो किसी test level, iteration या रिलीज़ के अंत में बनती है; ISO/IEC/IEEE 29119-3 चालू रिपोर्ट को test status report के रूप में दर्ज करता है। Progress report बताती है कि testing plan के मुक़ाबले कहाँ है, क्या blocked है और किस पर फ़ैसला चाहिए। Completion report सारांश देती है कि क्या टेस्ट हुआ, plan से विचलन, प्रोडक्ट की quality, residual risks और सीखे गए सबक़।
एक dashboard हर पाठक के लिए नहीं चलता। हर audience के लिए अलग view बनाएँ और सबमें परिभाषाएँ एक जैसी रखें।
- टीम (रोज़) — owners के साथ failing और blocked tests, नए defects, flaky tests, environment की स्थिति।
- Delivery या project manager (हर हफ़्ते या हर sprint) — risk level के हिसाब से plan के मुक़ाबले progress, severity के हिसाब से खुले defects और उनका trend, blockers, forecast।
- Release owner और executives (हर रिलीज़) — go/no-go सारांश, सरल भाषा में residual risk, खुले critical defects, रिलीज़ दर रिलीज़ escape rate का trend।
- हमेशा snapshots के पार trend, डेटा की तारीख़ और स्रोत, और एक लाइन की व्याख्या दिखाएँ। बिना व्याख्या का chart पाठक के लिए homework है।
एक पेज की sample test status report
नीचे की रिपोर्ट एक काल्पनिक रिलीज़ (Checkout v2, रिलीज़ 5.3) के 10 में से 7वें दिन की है, और उसकी कुल स्थिति AMBER है: scope plan के मुताबिक़ है, पर दो risks पर फ़ैसला चाहिए। Progress तालिका risk level के हिसाब से बँटी है: Very high के सभी 46 टेस्ट execute हुए, 44 pass और 2 fail; High के 38 में से 31 execute हुए (29 pass, 2 fail), 4 blocked और 3 नहीं चले; Medium/Low के 64 में से सिर्फ़ 30 execute हुए। Executed का मतलब passed + failed है; blocked और not run अलग दिखाए जाते हैं।
Pass rate = passed ÷ executed, यानी 103 ÷ 107 ≈ 96%; इसमें blocked और not run शामिल नहीं हैं, और flaky re-runs भी बाहर रखे गए हैं (2 टेस्ट quarantine में)। पास होते टेस्ट वाले acceptance criteria 84 में से 71 (85%) हैं, जो दिन 5 पर 62% थे — यही trend है। खुले defects: Blocker 0, Critical 1 — CHK-231 (gateway retry पर duplicate order, fix review में), Major 3, Minor 6। चार blocked टेस्ट 3-D Secure के हैं क्योंकि issuer sandbox बंद है; उनका owner और ETA दर्ज है। रिपोर्ट दो फ़ैसलों के साथ ख़त्म होती है: R5 के लिए आंशिक device coverage स्वीकार करें या टेस्टिंग एक दिन बढ़ाएँ, और क्या CHK-214 खुला रहते हुए queue-length alert के साथ रिलीज़ करें।
Executed = passed + failed; blocked और not run अलग दिखाए जाते हैं। Pass rate = passed ÷ executed: 103 ÷ 107 ≈ 96%।
TEST STATUS REPORT — Checkout v2 · Release 5.3 · Day 7 of 10 · data as of 24 Sep 2026 17:00
Overall: AMBER — scope on track; two risks need a decision
Progress by risk Planned Executed Passed Failed Blocked Not run
Very high 46 46 44 2 0 0
High 38 31 29 2 4 3
Medium / Low 64 30 30 0 0 34
Total 148 107 103 4 4 37
Acceptance criteria with a passing test: 71 of 84 (85%) day 5: 62%
Pass rate (passed / executed): 96% flaky re-runs excluded: 2 tests quarantined
Defects open: Blocker 0 · Critical 1 · Major 3 · Minor 6
CHK-231 Critical — duplicate order created on gateway retry (fix in review)
This period: 5 new · 7 closed · 1 reopened
Blocked: 4 tests on 3-D Secure — issuer sandbox down since 22 Sep (owner: DevOps, ETA 25 Sep)
Risks: R5 device coverage 2 of 4; R6 email delay (CHK-214) open
Decisions needed:
1. Accept partial device coverage for R5, or extend testing by one day
2. Release with CHK-214 open and a queue-length alert in place?
Next: finish High-risk tests, retest CHK-231, full regression run on day 9Test metrics की सीमाएँ और दुरुपयोग
Metrics व्यवहार बदलते हैं। जब कोई संख्या ऐसा target बन जाती है जिससे लोगों को आँका जाता है, तो लोग संख्या को optimise करते हैं, और वह उस चीज़ को मापना बंद कर देती है जिसके लिए बनी थी — इस विचार को आमतौर पर Goodhart’s law कहा जाता है। नुकसान सबसे ज़्यादा तब होता है जब metrics से व्यक्तियों की रैंकिंग की जाती है या अलग-अलग प्रोडक्ट पर काम करने वाली टीमों की तुलना की जाती है।
- Vanity metrics — test cases की कच्ची संख्या, हर tester के raise किए bugs, automated tests का प्रतिशत। इन्हें quality सुधारे बिना बढ़ाना आसान है।
- Gaming — एक defect को पाँच रिपोर्ट में बाँटना, गिनती बढ़ाने के लिए मामूली tests लिखना, defect age घटाने के लिए "cannot reproduce" कहकर बंद करना, code coverage बढ़ाने के लिए बिना assertion वाले tests जोड़ना।
- टीमों की तुलना — टीमों के बीच defect density या pass rate अलग-अलग प्रोडक्ट, risk level, गिनती के नियम और reporting संस्कृति को मिला देता है। हर टीम की तुलना उसके अपने अतीत से करें।
- बुरी ख़बर की सज़ा — अगर ज़्यादा defects उन्हें खोजने वाली टीम पर ही बुरे लगें, तो defects कम रिपोर्ट होंगे, कम बनेंगे नहीं।
- झूठी सटीकता — छोटे या असंगत sample (तीन रिलीज़, बदली हुई severity scheme) से निकाला प्रतिशत उसी संदर्भ के साथ रिपोर्ट करें, या बिल्कुल न करें।
इसके बजाय क्या मापें
- Test cases की संख्या की जगह → risk level के हिसाब से passing tests वाला requirement और risk coverage।
- हर tester के bugs की जगह → पूरी टीम का defect escape rate और root cause के हिसाब से defects।
- अकेले pass rate की जगह → executed बनाम planned, blocked tests और trend के साथ pass rate।
- Code coverage target की जगह → high-risk modules में बिना कवर हुए code की सूची, और वहाँ assertion review या mutation testing।
- Automation प्रतिशत की जगह → automated checks से कवर हुए regression risks का हिस्सा, suite की अवधि और flaky rate।
- हर developer के fix किए defects की जगह → component के हिसाब से defect age और reopen rate।
- टीमों की league table की जगह → हर टीम का अपना trend, उसकी retrospective में चर्चा किया हुआ।
अक्सर पूछे जाने वाले सवाल
सबसे अहम test metrics कौन-से हैं?
ज़्यादातर टीमों के लिए: passing tests के साथ requirement या acceptance-criteria coverage, risk level के हिसाब से risk coverage, severity के हिसाब से खुले defects, रिलीज़ दर रिलीज़ defect escape rate, और automated regression suite की health। इन्हें उन फ़ैसलों से चुनें जो आपको लेने हैं।
Defect detection percentage कैसे निकालें?
रिलीज़ से पहले मिले defects को, रिलीज़ से पहले मिले और तय window में रिलीज़ के बाद मिले defects के योग से भाग दें, और 100 से गुणा करें। उदाहरण: 45 पहले और 5 बाद में, तो 90%। Escape rate बाक़ी 10% है।
क्या 100% code coverage अच्छा लक्ष्य है?
नहीं। Code coverage बताता है कि tests के दौरान कौन-सा code चला, यह नहीं कि tests ने नतीजे जाँचे या नहीं। इसे बिना टेस्ट हुए code, ख़ासकर high-risk modules में, खोजने के लिए इस्तेमाल करें, और tests की quality assertions की review या mutation testing से आँकें।
Test progress report और test completion report में क्या अंतर है?
Progress report testing के दौरान नियमित रूप से बनती है और plan के मुक़ाबले स्थिति, blockers और ज़रूरी फ़ैसले दिखाती है। Completion report किसी level, iteration या रिलीज़ के अंत में बनती है और नतीजे, विचलन, residual risks और सबक़ का सारांश देती है।
DORA metrics क्या हैं?
DORA के पाँच software delivery metrics: change lead time, deployment frequency और failed deployment recovery time (throughput), और change fail rate व deployment rework rate (instability)। ये delivery system को मापते हैं, और testing इन पर गहरा असर डालती है।
क्या test metrics से व्यक्तिगत testers का मूल्यांकन करना चाहिए?
यह आम दुरुपयोग है। हर व्यक्ति के raise किए bugs या execute किए tests जैसी गिनतियों से खेलना आसान है और ये सहयोग और prevention के काम को हतोत्साहित करती हैं। नतीजों को टीम स्तर पर आँकें और व्यक्तिगत काम पर गुणात्मक चर्चा करें।
Test metrics कितनी बार रिपोर्ट करने चाहिए?
सक्रिय testing के दौरान टीम के लिए रोज़, delivery management के लिए हर हफ़्ते या हर sprint, और release owner के लिए हर रिलीज़। आवृत्ति जो भी हो, एक snapshot नहीं, trend और डेटा की तारीख़ दिखाएँ।
संदर्भ
- Certified Tester Advanced Level Test Management (CTAL-TM) v3.0टेस्टिंग प्रबंधन पर ISTQB का advanced पाठ्यक्रम: टेस्ट योजना और अनुमान, risk-based testing, निगरानी, मेट्रिक्स और रिपोर्टिंग।
- ISTQB Certified Tester Foundation Level (CTFL) v4.0सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
- ISO/IEC/IEEE 29119-3:2021 — Software and systems engineering — Software testing — Part 3: Test documentationटेस्ट दस्तावेज़ों के टेम्पलेट और सामग्री — test policy, strategy, plan, status व completion रिपोर्ट, incident रिपोर्ट।
- DORA's software delivery performance metricsDORA के डिलीवरी मेट्रिक्स — change lead time, deployment frequency, failed deployment recovery time, change fail rate आदि — throughput और instability में समूहित।
- ISTQB Glossaryटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
अभ्यास
भ्रामक release status report को raw data से दोबारा बनाएँ
आप एक retail bank के mobile app (काल्पनिक) में Bill payments feature टेस्ट करते हैं। Release 8.4 की system testing 8 में से 6वें दिन पर है, और कल सुबह release owner तय करेगा कि release अपनी तारीख़ पर रहेगी या नहीं। Team lead ने उस meeting के लिए एक dashboard का draft बनाया है; test management tool और defect tracker से निकाला गया raw data नीचे है।
फ़ैसले के लिए ज़रूरी metrics निकालें, draft की हर line review करें, और एक छोटा status section लिखें जिस पर release owner कार्रवाई कर सके — CTFL की भाषा में, यह test progress report का वह हिस्सा है जो release owner देखता है। काग़ज़-पेन या percentage calculator इस्तेमाल करें, और प्रतिशत को पूरे अंकों में round करें।
Mobile banking app · Bill payments · Release 8.4 · system testing day 6 of 8
Exported 14 Sep 2026 16:00 from the test management tool and the defect tracker
Test results by risk level Planned Passed Failed Blocked Not run
Very high 40 30 2 6 2
High 50 44 3 0 3
Medium / Low 90 88 0 0 2
Acceptance criteria: 60 in total
52 have at least one linked test
45 have a linked test that passed in this cycle
Day 4 export: 31 had a linked test that passed
Blocked: the 6 Very high tests of biller payment confirmation; the biller
sandbox has returned HTTP 503 since 12 Sep; no owner assigned
Open defects: Blocker 0 · Critical 2 · Major 4 · Minor 7
BP-118 Critical payment debited twice when "Pay" is tapped twice quickly
BP-131 Critical scheduled payment runs one day late at month end
BP-077 Major oldest open defect, open for 41 days
Days open for each of the 13 open defects (tracker order): 3 41 1 4 2 7 3 1 5 3 2 6 4
This cycle: 25 defects resolved; 4 of them reopened after retest
Earlier releases Found before release Reported by customers in 30 days
Release 8.2 38 2
Release 8.3 42 8
Team lead’s draft dashboard for the release owner:
Status: GREEN
Pass rate: 97%
Test cases in the repository: 1,240 (+140 this release)
Code coverage: 88%
Bugs raised per tester: Huda 14 · Ravi 9 · Omar 3- हर risk level और कुल के लिए executed tests (passed + failed) और pass rate (passed ÷ executed) निकालें, और यह भी कि planned में से कितने Very high tests pass हुए।
- Acceptance-criteria coverage दो तरह से निकालें — कम से कम एक linked test वाले criteria, और passing test वाले criteria — और दिन 4 से अब तक का trend।
- Release 8.2 और 8.3 के लिए defect detection percentage (DDP) और escape rate निकालें। क्या Release 8.4 के लिए इन्हें अभी निकाला जा सकता है?
- इस cycle का reopen rate, और खुले defects की age का median और mean निकालें। तय करें कि कौन-सा age आँकड़ा रिपोर्ट करेंगे और उसके साथ क्या जोड़ेंगे।
- Draft dashboard की हर line review करें: रखें, ठीक करें या हटाएँ, और कारण बताएँ।
- Status section लिखें: overall status, data की तारीख़ और स्रोत के साथ मुख्य संख्याएँ, owners के साथ blockers, और वे फ़ैसले जो release owner को लेने हैं।
मॉडल उत्तर दिखाएँ
Execution। Executed = passed + failed: Very high में 40 planned में से 32, High में 50 में से 47, Medium / Low में 90 में से 88, कुल 180 में से 167 (93%)। Pass rate = passed ÷ executed: Very high 30 ÷ 32 = 94%, High 44 ÷ 47 = 94%, Medium / Low 88 ÷ 88 = 100%, कुल 162 ÷ 167 = 97%। Draft का 97% गणित में सही है, लेकिन असली बात छिपाता है: 40 Very high tests में से सिर्फ़ 30 pass हुए हैं (75%) — 2 fail, 6 blocked और 2 not run। Blocked और not-run tests pass rate में आते ही नहीं, इसलिए उन्हें उसके साथ, risk level के हिसाब से, दिखाना ज़रूरी है।
Coverage। कम से कम एक linked test वाले criteria: 60 में से 52 (87%)। Passing test वाले criteria: 60 में से 45 (75%) — रिलीज़ के समय सिर्फ़ इसी आँकड़े का मतलब है। 15 criteria का gap दो हिस्सों में है: 8 जिनका कोई test ही नहीं, और 7 जिनके tests अभी pass नहीं हुए (fail, blocked या not run)। Trend अच्छा है — दिन 4 पर 60 में से 31 (52%), दिन 6 पर 60 में से 45 (75%) — लेकिन दो दिन बचे हैं, इसलिए बिना test वाले 8 criteria को या तो tests चाहिए या उन्हें बाहर रखने का स्पष्ट फ़ैसला।
Defect detection। Release 8.2: DDP = 38 ÷ (38 + 2) × 100 = 95%, escape rate 2 ÷ 40 = 5%। Release 8.3: DDP = 42 ÷ (42 + 8) × 100 = 84%, escape rate 8 ÷ 50 = 16%। दोनों releases के बीच escape rate बढ़ा है, लेकिन सिर्फ़ दो releases और एक अंक वाली गिनतियों के साथ इसे उसी संदर्भ के साथ रिपोर्ट करें; इसे साबित trend नहीं, बल्कि इस बात का कारण मानें कि 8 escaped defects के root causes की review हो और जाँचा जाए कि दोनों releases में गिनती के नियम एक जैसे थे (वही 30 दिन की window, वही severities)। Release 8.4 का DDP अभी नहीं निकल सकता: उसके लिए रिलीज़ के बाद 30 दिनों में customers के रिपोर्ट किए defects चाहिए, इसलिए अभी दी गई कोई भी संख्या झूठी सटीकता होगी।
Defects। Reopen rate = 4 ÷ 25 = 16%। तुलना के लिए कोई बाहरी benchmark नहीं है; इसकी तुलना इसी टीम के पिछले cycles से करें, और baseline जो भी हो, एक cycle में चार reopen हुए fixes triage में उठाने लायक हैं: अधूरे fixes, अस्पष्ट रिपोर्ट या कमज़ोर retesting। Defect age: 13 values क्रम से 1 1 2 2 3 3 3 4 4 5 6 7 41 हैं, इसलिए median 7वीं value यानी 3 दिन है; mean 82 ÷ 13 ≈ 6.3 दिन है, जो एक ही defect की वजह से median के दोगुने से ज़्यादा है। Median रिपोर्ट करें और सबसे पुराने खुले item का नाम लें: BP-077, Major, 41 दिन से खुला, जिस पर फ़ैसला चाहिए — fix करें या स्पष्ट रूप से defer करें।
Draft review। "Status: GREEN" — ठीक करें: payment flow में बिना acceptance फ़ैसले के दो खुले Critical defects और बिना owner के 6 blocked Very high tests green नहीं हैं। "Pass rate: 97%" — रखें, लेकिन सिर्फ़ risk level के हिसाब से executed बनाम planned, blocked और not-run tests के साथ, और data की तारीख़ के साथ। "Test cases in the repository: 1,240" — हटाएँ: test cases की कच्ची संख्या vanity metric है और quality सुधारे बिना बढ़ सकती है; इसकी जगह passing test वाला acceptance-criteria coverage और planned में से pass हुए Very high tests दिखाएँ। "Code coverage: 88%" — release owner के view से हटाएँ: यह नहीं बताता कि statement coverage है या branch, किस build का है, कौन-सा code कवर नहीं हुआ, और यह भी नहीं दिखाता कि tests नतीजे जाँचते हैं; developers से payment confirmation और scheduling modules में बिना कवर हुए code की सूची माँगें और वहाँ assertions की review करें। "Bugs raised per tester" — हटाएँ: यह व्यक्तियों की रैंकिंग करता है, gaming को बढ़ावा देता है (जैसे एक defect को कई रिपोर्ट में बाँटना), सहयोग को हतोत्साहित करता है और किसी release फ़ैसले में काम नहीं आता; defects पूरी टीम के स्तर पर दिखाएँ (severity, reopen rate, escape rate और root cause के हिसाब से)। Draft में data की तारीख़ और स्रोत, कोई trend और एक लाइन की व्याख्या भी नहीं है।
Overall status: AMBER, GREEN नहीं। Scope अब भी समय पर पूरा हो सकता है अगर biller sandbox को owner मिल जाए और वह फिर से चलने लगे, और दोनों Critical defects fix होकर retest हो जाएँ; आज sandbox का कोई owner नहीं है और दोनों defects अभी खुले हैं। यह भी लिखें कि status RED कब होगा: जैसे कल सुबह तक sandbox का owner न हो, या दिन 7 तक दोनों Critical defects fix और retest न हों। रंग अपनी टीम की लिखित परिभाषा के अनुसार चुनें; अगर RED का मतलब "आज कोई release criterion पूरा नहीं है" है, तो status RED है। ज़रूरी यह है कि रंग अपने कारणों के साथ आए। और फ़ैसले से शुरू करें: release owner को जानना है कि payment risks टेस्ट हुए या नहीं और कोई ज्ञात payment defect बचा है या नहीं, इसलिए रिपोर्ट में सबसे ऊपर Very high row और Critical defects आते हैं, कुल pass rate नहीं।
एक status section जिस पर release owner कार्रवाई कर सके: "Bill payments, Release 8.4, system testing 8 में से दिन 6 — data 14 Sep 2026 16:00 तक का, test management tool और defect tracker से। Overall: AMBER — तारीख़ ख़तरे में है और तीन फ़ैसले चाहिए। Very high risk: 40 में से 30 tests pass, 2 fail, 6 blocked, 2 not run। सभी levels: 180 में से 167 executed, executed में से 97% pass। Passing test वाले acceptance criteria: 60 में से 45 (75%), दिन 4 पर 52% थे; 8 criteria का कोई test नहीं। खुले defects: Blocker 0, Critical 2 (BP-118 जल्दी double tap करने पर दो बार debit; BP-131 month end पर scheduled payment एक दिन देर से), Major 4, Minor 7; इस cycle में 25 में से 4 fixes reopen हुए; खुले defects की median age 3 दिन, सबसे पुराना BP-077 (Major) 41 दिन से खुला, जिसे triage में fix या स्पष्ट रूप से defer करना है। Blocked: payment confirmation के 6 tests, biller sandbox 12 Sep से HTTP 503 लौटा रहा है, कोई owner नहीं। संदर्भ: escape rate 8.2 में 5% और 8.3 में 16% (सिर्फ़ दो releases, छोटी गिनतियाँ), root-cause review planned। ज़रूरी फ़ैसले: 1. आज ही sandbox का owner तय करें; अगर दिन 7 तक वह वापस न आए तो testing बढ़ाएँ या तारीख़ आगे करें। 2. BP-118 और BP-131 के fix और retest के बाद ही release करें, या risk को लिखित रूप में स्पष्ट रूप से स्वीकार करें (testing टीम की सिफ़ारिश: double debit खुला रहते release नहीं)। 3. बिना test वाले 8 criteria के tests जोड़ें या उन्हें स्वीकार किए गए gaps के रूप में दर्ज करें।"
अगर आपकी संख्याएँ अलग आएँ, तो जाँचें कि executed में सिर्फ़ passed और failed tests गिने गए हैं, कि रिपोर्ट किया गया coverage "passing test वाला" है, और कि median क्रम से लगाई गई सूची से लिया गया है।
इस topic में आपकी प्रगति
प्रगति ट्रैक करने के लिए साइन इन करें
Topics पूर्ण चिह्नित करें, जहाँ छोड़ा था वहीं से जारी रखें और specialisation परीक्षाएँ खोलें।
QA रोडमैप का हिस्सा
इस गाइड में बताए गए टूल्स
Mutqan AI से requirements या किसी user story की तुलना मौजूदा टेस्ट केस से करके अनटेस्टेड हिस्से खोजें।
क्रमांकित आवश्यकताओं की सूची को requirement-to-test मैट्रिक्स के साथ ट्रेस करने योग्य टेस्ट केस में बदलें।
coverage मैपिंग के साथ functional आवश्यकताओं से टेस्ट सिनेरियो निकालें।
फ़ीचर को संभावना और प्रभाव के आधार पर स्कोर दें, फिर प्राथमिकता वाला risk-based टेस्ट प्लान जनरेट करें।
बदलाव के विवरण और प्रभावित तथा संबंधित मॉड्यूल की सूची से रिग्रेशन सिनेरियो जनरेट करें।