एक्ज़िक्यूशन रिपोर्टिंग
Execution reporting वह तरीका है जिससे tester टीम को बताता है कि test run में क्या हुआ: कितने tests चले, उन्होंने क्या पाया, क्या टेस्ट नहीं हो सका, और release के लिए इसका क्या मतलब है। रोज़ के काम में इसके दो रूप हैं: हर execution दिन के अंत में एक छोटा daily status, और run या cycle ख़त्म होने पर run summary।
उदाहरण के लिए, "90 में से 51 tests executed, 45 pass, 6 fail, 8 blocked" टीम को बताता है कि run कहाँ तक पहुँचा। "एक Critical defect rejected prescription वाले order को आगे जाने देता है, और सभी payment tests blocked हैं" बताता है कि ख़तरे में क्या है, और लोग उसी हिस्से पर कदम उठाते हैं।
यह क्यों ज़रूरी है
Release और fix के फ़ैसले इन्हीं reports से होते हैं, अक्सर ऐसे लोगों द्वारा जो test management tool कभी नहीं खोलते, इसलिए वे counts ख़ुद नहीं जाँच सकते। अगर attempts को tests गिना जाए, या blocked tests को executed, तो totals progress को बढ़ा-चढ़ाकर दिखाते हैं और कोई नहीं बता सकता कि product का कितना हिस्सा सच में टेस्ट हुआ। साफ़ daily reporting समस्याओं को तब action में बदलती है जब अभी समय बचा हो।
Tester के लिए, हमेशा जुड़कर सही बैठने वाले numbers और सच निकलने वाले risks भरोसा बनाते हैं: लोग आपका status सबसे पहले पढ़ते हैं। और अगर कोई defect production तक पहुँच जाए, तो लिखा हुआ record दिखाता है कि क्या टेस्ट हुआ, क्या नहीं हुआ, और किसने कौन-सा risk स्वीकार किया।
दो reports: daily status और run summary
एक test run के स्तर पर tester दो छोटी reports लिखता है। Daily status हर execution दिन के अंत में उन लोगों को जाता है जो रोज़ run के साथ काम करते हैं: test lead, developers और product owner। इसे एक मिनट में पढ़ा जा सके। Run summary एक बार लिखा जाता है, जब run या cycle ख़त्म होता है, और run के record के रूप में उसके साथ रहता है।
ISTQB की भाषा में daily status एक test progress report है: यह testing चलते समय बनती है ताकि test control समय पर प्रतिक्रिया दे सके, और ISO/IEC/IEEE 29119-3 ऐसी report को test status report कहता है। Run summary एक run को कवर करता है, जो आम तौर पर किसी test level का सिर्फ़ एक हिस्सा होता है, इसलिए वह अगली progress report और बाद में test completion report का input बनता है; छोटी टीम में वह ख़ुद उस cycle की test completion report का काम भी कर सकता है।
- Daily status: run, build और data लेने का समय; plan के मुक़ाबले counts; नए failed tests और blockers, हर एक के owner के साथ; ख़तरे में क्या है; आपको क्या चाहिए और किससे; कल का plan।
- Run summary: हर area या risk level के final counts; failures के पीछे के open defects; क्या टेस्ट नहीं हुआ और क्यों; बचे हुए risks; आपका assessment, साफ़ लिखकर कि यह आपकी राय है।
Results ऐसे गिनें कि numbers जुड़कर सही बैठें
Counts उन statuses से बनते हैं जो आपने test suites और test runs वाले lesson में सीखे। ISTQB Foundation syllabus run और not run, passed और failed test cases को आम test progress metrics में गिनाता है, और कई test management tools इसमें blocked जोड़ते हैं। एक definition counts को ईमानदार रखती है: test तब executed है जब वह किसी verdict तक चला, pass या fail। Blocked test चल ही नहीं सका, इसलिए वह न executed है न failed: product का वह हिस्सा बस अभी तक टेस्ट नहीं हुआ।
Attempts नहीं, tests गिनें। कुछ टीमें हर build के लिए नया run शुरू करती हैं, जैसा test suites और test runs वाले lesson में था; कुछ पूरे cycle के लिए एक ही run खुला रखती हैं और बाद के builds पर fixes का retest उसी में करती हैं। दोनों हालात में हर test एक बार गिना जाता है, अपने latest result के साथ: जो test सोमवार को fail हुआ और fix के बाद बुधवार को pass हुआ, वह एक passed test है, और failure defect report व test history में दर्ज रहती है। फिर हिसाब जाँचें: passed, failed, blocked और not run का जोड़, और अगर आपका run skipped status इस्तेमाल करता है तो skipped भी, planned total के बराबर होना चाहिए।
- Denominator हमेशा बताएँ: executed tests में से 86% pass हुए, लेकिन पूरे run का अभी सिर्फ़ 60% pass हुआ है।
- Skipped या descoped tests अपनी अलग line पर कारण और फ़ैसला करने वाले के नाम के साथ जाएँ, न कि plan से ग़ायब हो जाएँ ताकि progress बेहतर दिखे।
Run: 50 planned tests, end of day 2
Passed 30 + Failed 5 + Blocked 5 + Not run 10 = 50 planned (check)
Executed = Passed + Failed = 35
Progress = Executed / Planned = 35 / 50 = 70%
Pass rate = Passed / Executed = 30 / 35 = 86%
Passed of plan = Passed / Planned = 30 / 50 = 60%
Not executed = Blocked + Not run = 15 (30% of the run)Worked example: पाँच दिन का run, daily status से summary तक
एक pharmacy delivery app, release 1.8, का पाँच दिन का system test run है: चार areas में 90 planned tests, लगभग 18 रोज़। नीचे का block test management tool से हर दिन 17:00 बजे लिया गया run का progress दिखाता है, और उसके बाद day 5 के अंत में लिखा गया run summary।
Day 3 पर tester का daily status यह था: "Day 3 of 5: 90 में से 51 executed (plan 54); 45 pass, 6 fail, 8 blocked, 31 not run। Risk: Critical PH-231 rejected prescription वाले order को आगे जाने देता है। Card और wallet payment के सभी 8 tests day 2 से payment sandbox की वजह से blocked; owner: DevOps, restore की कोई तारीख़ नहीं। चाहिए: day 4 को 12:00 तक restore की तारीख़ या payment testing पर फ़ैसला। कल: order tracking और fixed defects के confirmation tests।"
हर bar 90 planned tests का पूरा run है, हर test एक बार अपने latest result के साथ गिना गया। Executed = passed + failed; blocked और not run executed नहीं हैं।
- Pass rate 88% से बढ़कर 95% हुआ, फिर भी 16 tests (18%) कभी executed नहीं हुए। Day 5 पर sandbox में card payments लौट आए, लेकिन wallet payment के 6 tests blocked रहे, और 10 Medium व Low tests के लिए समय नहीं बचा।
- Day 4 और day 5 पर failed count घटा, क्योंकि fixed defects ने अपने confirmation tests pass किए; हर test एक बार गिना जाता है, अपने latest result के साथ।
- Summary 4 failures के पीछे के 3 defects का नाम लेता है और बताता है कि क्या टेस्ट नहीं हुआ। Tester का assessment, साफ़ तौर पर अपना बताकर: PH-231 open रहते ready नहीं; wallet payments के लिए product owner sandbox का इंतज़ार करने और wallet बंद करके release करने में से एक चुने।
TEST RUN: Pharmacy app 1.8 · system test, cycle 1 · builds 1.8.0-rc1 to rc3 on staging
Planned: 90 tests in 5 days (18 a day) · latest result per test · data at 17:00
Day Executed Passed Failed Blocked Not run Pass rate
1 16 14 2 0 74 88%
2 34 30 4 8 48 88%
3 51 45 6 8 31 88%
4 63 58 5 8 19 92%
5 74 70 4 6 10 95%
RUN SUMMARY · end of day 5
Area (risk) Plan Passed Failed Blocked Not run
Prescription upload (High) 20 17 3 0 0
Checkout & payment (High) 24 17 1 6 0
Order tracking (Medium) 26 22 0 0 4
Profile & notifications (Low) 20 14 0 0 6
Total 90 70 4 6 10
Open defects behind the 4 failed tests
PH-231 Critical order accepted with a rejected prescription (2 tests)
PH-236 Major PDF prescriptions cannot be uploaded (1 test)
PH-240 Minor delivery fee shown as 7.5 instead of 7.50 (1 test)
Not tested: wallet payments, 6 tests blocked (payment sandbox down since day 2)
10 Medium and Low tests not run (out of time)
Remaining risk: prescription check can be bypassed; wallet payments untestedआज़माएँ: Markdown फ़ॉर्मेटर आज़माएँ: Markdown को PDF में बदलें
आम गलतियाँ
- Tests की जगह attempts गिनना: fix के बाद retest हुआ test दो बार गिना जाता है, या उसकी पुरानी failure अब भी pass rate के ख़िलाफ़ गिनी जाती है।
- Blocked tests को executed या failed गिनना, जिससे चारों counts का जोड़ plan के बराबर नहीं रहता।
- Skipped tests को चुपचाप plan से हटाना, या run के बीच कोई definition बदलना, ताकि progress असल से बेहतर दिखे।
QA का नज़रिया
हर दिन उसी समय test management tool से numbers लें, जाँचें कि उनका जोड़ plan के बराबर है, और लिखने से पहले नए failures और blockers पढ़ें: risk वाली lines वहीं से आती हैं, totals से नहीं। अच्छी report में क्या होता है, उसे हर पाठक के हिसाब से कैसे ढालें, और blocker को daily status का इंतज़ार किए बिना उसी दिन क्यों उठाया जाता है, इसके लिए test reporting वाला lesson देखें।
अभ्यास
Tool export से सही counts निकालें
आप एक school fees portal टेस्ट कर रहे हैं। नीचे चार दिन के regression run के day 2 का 16:00 बजे का raw data है, और tool export tests नहीं, execution attempts गिनता है। सही counts निकालें, उन्हें plan से मिलाएँ, और daily status की counts वाली line लिखें।
फिर बताएँ कि अगर आप export को जैसा है वैसा copy कर देते, तो टीम क्या पढ़ती।
Run: School fees portal 2.3 · regression run · day 2 of 4 · data at 16:00
Planned: 64 tests · plan for the end of day 2: 32 executed
Tool export (one row per execution attempt, not per test)
attempts: 41 passed: 29 failed: 7 blocked: 5
From the tester's log
TC-17, TC-18, TC-19 failed on rc1 (defect FEE-512); FEE-512 was fixed and
all three passed on rc2. Both attempts of each test are in the export.
Blocked: 5 installment-plan tests; the bank test API is down (HTTP 503)
since 10:00; owner: integration team; no estimate
Open: FEE-520 Critical paying one installment marks the whole fee as paid
(2 failed tests)
FEE-523 Minor receipt date in the wrong format (2 failed tests)- Attempts को tests में बदलें: हर test एक बार, अपने latest result के साथ गिना जाता है।
- Executed, not run, progress और pass rate निकालें, और जाँचें कि counts का जोड़ 64 है।
- अपने counts की export से तुलना करें और हर अंतर समझाएँ।
- Counts वाली line लिखें: plan के मुक़ाबले executed, फिर passed, failed, blocked और not run।
मॉडल उत्तर दिखाएँ
गिनती: 41 attempts में TC-17, TC-18 और TC-19 दो बार हैं, एक बार rc1 पर fail और एक बार rc2 पर pass। Latest result रखने पर 38 tests का result है: 29 passed, 4 failed (FEE-520 और FEE-523, दोनों के दो-दो tests) और 5 blocked। Not run = 64 − 38 = 26। जाँच: 29 + 4 + 5 + 26 = 64।
Numbers: executed = 29 + 4 = 33, यानी 64 में से 33 (52%), plan 32 के मुक़ाबले, इसलिए run plan पर है। Pass rate = 29 ÷ 33 = 88%। Export को जैसा है वैसा पढ़ने पर 41 "executed" tests और 7 failures निकलते, क्योंकि वह तीन tests को दो बार गिनता है और 5 blocked attempts को ऐसे गिनता है मानो वे चले हों। सिर्फ़ उसके passed और failed attempts से भी 29 ÷ 36 = 81% निकलता है, क्योंकि rc1 की वे तीन failures, जो बाद में fix हो गईं, अब भी गिनी जाती हैं।
Counts वाली line: "School fees 2.3 regression, day 2 of 4 (16:00, rc2): 64 में से 33 executed (52%, plan 32); 29 pass, 4 fail, 5 blocked, 26 not run; executed tests का pass rate 88%।" उसके बाद की lines, Critical FEE-520, installment के blocked tests और उनका owner, और आपको क्या चाहिए, test reporting वाले lesson की तरह लिखी जाती हैं।
अक्सर पूछे जाने वाले सवाल
क्या blocked tests को executed गिना जाता है?
नहीं। वे अभी not run tests के साथ not executed में गिने जाते हैं, और status उन्हें blocker, उसके owner और कब से, के साथ अलग दिखाता है। उन्हें executed गिनने से progress बढ़ा-चढ़ाकर दिखता है; failed गिनने से developers ऐसे defects ढूँढने लगते हैं जो शायद हैं ही नहीं। Blocker हटने पर जब blocked test चलता है, तो उसका latest result उसे passed या failed में ले जाता है।
अच्छा pass rate कितना होता है?
कोई universal target नहीं है। Pass rate सिर्फ़ उन tests के बारे में बताता है जो चले, और उसका मतलब इस पर निर्भर है कि वे कौन-से tests थे। Test plan के exit criteria तय करते हैं कि अंत में क्या सच होना चाहिए, जैसे सभी high-risk tests pass और कोई open Critical defect नहीं। Pass rate को हर area के लिए और समय के साथ track करें, और हमेशा not executed tests की संख्या के साथ दिखाएँ।
Daily stand-up होता है तो क्या लिखित daily status ज़रूरी है?
आम तौर पर हाँ, लेकिन उसे छोटा रखें। Stand-up मौखिक होता है और सिर्फ़ मौजूद लोगों तक पहुँचता है; लिखित status उन stakeholders तक पहुँचता है जो वहाँ नहीं थे, numbers को traceable रखता है और वह history बनाता है जिससे run summary लिखा जाता है। Blockers stand-up में या तुरंत उठाएँ, और फिर लिखित में पक्का करें।
संदर्भ
- 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 रिपोर्ट।
- ISTQB Glossaryटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
Mutqan tools से अभ्यास करें
प्रतिशत, प्रतिशत परिवर्तन, वृद्धि/कमी और X, Y का कितना प्रतिशत है — सब गिनें।
Markdown की फ़ॉर्मेटिंग (हेडिंग, सूचियाँ, टेबल, emphasis) सामान्य करें और रेंडर किया नतीजा देखें।
Markdown (.md) फ़ाइलों को ब्राउज़र में PDF में बदलें: शीर्षक, सूचियाँ, तालिकाएँ, कोड ब्लॉक, उद्धरण, लिंक और चित्र एम्बेडेड फ़ॉन्ट से टाइपसेट।
और गहराई से
इस topic में आपकी प्रगति
प्रगति ट्रैक करने के लिए साइन इन करें
Topics पूर्ण चिह्नित करें, जहाँ छोड़ा था वहीं से जारी रखें और specialisation परीक्षाएँ खोलें।