टेस्ट रिपोर्टिंग

Mutqan Soft QA टीम द्वारा · अपडेट 6 अक्टूबर 2026 · 18 मिनट · शुरुआती

Test reporting वह तरीका है जिससे testing दूसरों को बताती है कि वह कहाँ खड़ी है, उसने क्या पाया और कौन-सा risk बाक़ी है, ताकि फ़ैसला करने वाले सही फ़ैसला कर सकें। ISTQB Foundation syllabus v4.0 दो तरह की reports बताता है: test progress report, जो testing चलते समय नियमित रूप से बनती है और test control में मदद करती है, और test completion report, जो testing का कोई stage ख़त्म होने पर बनती है (कोई test level, cycle, iteration या project), आदर्श रूप से exit criteria पूरे होने के बाद।

उदाहरण: एक clinic booking app के दस दिन के system test में tester product owner को रोज़ छोटी progress report भेजता है: 80 planned tests में से कितने चले, कौन-सा defect तारीख़ के लिए ख़तरा है और कौन-सा फ़ैसला चाहिए। अंत में completion report बताती है कि exit criteria के मुक़ाबले क्या टेस्ट हुआ और release करके टीम कौन-से risks स्वीकार कर रही है।

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

जो जानकारी उस व्यक्ति तक न पहुँचे जो उस पर कदम उठा सकता है, वह बेकार जाती है। Spreadsheet में दबा एक Critical defect, एक blocked environment जिसे किसी ने escalate नहीं किया, या 90% pass rate जो बिना टेस्ट हुए हिस्से को छिपा देता है: सबका नतीजा एक है। Release ऐसे risk के साथ चला जाता है जिसे किसी ने जानते-बूझते स्वीकार नहीं किया, या deadline बिना चेतावनी के खिसक जाती है।

Tester के लिए reports भरोसा बनाती हैं: राय से अलग रखे गए तथ्य और साफ़ माँगे गए फ़ैसले testing को जानकारी का स्रोत दिखाते हैं, न कि ऐसा gate जो बस "ready नहीं है" कहता है।

Test progress report और test completion report

Test progress report, test monitoring और control का हिस्सा है। ISTQB glossary इसे एक periodic report बताता है जो किसी baseline, जैसे test plan, के मुक़ाबले test activities की progress, risks और फ़ैसला माँगने वाले alternatives बताती है। यह नियमित अंतराल पर बनती है (रोज़, हर हफ़्ते या हर sprint) और इसमें इतनी जानकारी होनी चाहिए कि testing के plan से हटने पर या हालात बदलने पर schedule, resources या test plan बदले जा सकें। यह जवाब देती है: क्या हम plan पर हैं, रास्ते में क्या रुकावट है, और किस पर फ़ैसला चाहिए?

Test completion report test completion के दौरान तैयार होती है, जब कोई test level, cycle, iteration या project ख़त्म होता है। पूरे stage की progress reports और दूसरे data से बनकर यह test objectives और exit criteria के मुक़ाबले testing और product quality का मूल्यांकन करती है, और आगे की testing को जानकारी देती है। यह जवाब देती है: हमने क्या टेस्ट किया, product कितना अच्छा है, और कौन-सा risk बाक़ी है?

ISO/IEC/IEEE 29119-3 दोनों के templates देता है और progress report को test status report कहता है; कुछ टीमें, और पुराने syllabi, completion report को test summary report कहते हैं।

Progress report: testing period; plan के मुक़ाबले progress, notable deviations समेत; impediments और उनके workarounds; test metrics; नए और बदले हुए risks; अगले period के लिए planned testing।
Completion report: test summary; test objectives और exit criteria के मुक़ाबले testing और product quality का मूल्यांकन; schedule, duration और effort में plan से deviations; impediments और workarounds; progress reports पर आधारित metrics; unmitigated risks और जो defects fix नहीं हुए; lessons learned।

Test progress report चलती testing को दिशा देती है; test completion report ख़त्म हुए stage को exit criteria के मुक़ाबले समेटती है और दर्ज करती है कि क्या खुला रह गया।

Test progress reportTesting के दौरान

चलती testing को दिशा देती है

कब:: नियमित: रोज़, हर हफ़्ते या हर sprint
किस सवाल का जवाब:: क्या हम plan पर हैं, रास्ते में क्या है, किस पर फ़ैसला चाहिए?
किससे बनती है:: मौजूदा period का monitoring data
किस काम आती है:: Test control: schedule, resources या test plan में बदलाव
Formality:: टीम के अंदर अक्सर छोटी और informal
दूसरा नाम:: Test status report (ISO/IEC/IEEE 29119-3)

Test completion reportStage ख़त्म होने पर

ख़त्म हुए stage को समेटती है और आगे की testing को जानकारी देती है

कब:: एक बार, जब कोई test level, cycle, iteration या project ख़त्म हो, आदर्श रूप से exit criteria पूरे होने पर
किस सवाल का जवाब:: क्या टेस्ट किया, product कितना अच्छा है, कौन-सा risk बाक़ी है?
किससे बनती है:: पूरे stage की progress reports और दूसरा data
किस काम आती है:: Acceptance या release के फ़ैसलों और आगे की testing के लिए input
Formality:: तय template, एक बार लिखी जाती है और record के रूप में रखी जाती है
दूसरा नाम:: Test summary report (पुराना नाम)

वही तथ्य, अलग-अलग पाठक

Syllabus बताता है कि अलग-अलग audience को अलग जानकारी चाहिए, और audience ही formality और frequency तय करती है: टीम के अंदर reporting अक्सर बार-बार और informal होती है, जबकि completion report तय template पर चलती है और एक ही बार लिखी जाती है। Channels stand-up में बातचीत, CI/CD dashboard, task board या burn-down chart (बचा हुआ काम, दिन-ब-दिन plot किया हुआ) से लेकर chat, email, wiki page या formal report तक होते हैं; अलग-अलग जगहों या time zones में फैली टीमों को अक्सर ज़्यादा formal और लिखित reporting चाहिए।

Depth बदलें, तथ्य नहीं: हर पाठक को वही numbers, वही परिभाषाओं के साथ मिलें।

Developers और टीम, रोज़: failing और blocked tests, owners के साथ defect IDs, environment की समस्याएँ।
Product owner या project manager, हर हफ़्ते या हर sprint, और testing रुकने पर तुरंत: feature या risk के हिसाब से progress, severity के हिसाब से खुले defects, impediments, ज़रूरी फ़ैसले।
Sponsor या senior management, हर release पर, एक page में: सरल शब्दों में status, residual risks और हर विकल्प की क़ीमत।
Auditors या regulated client, जहाँ लागू हो: तय template पर formal completion report, requirements से results तक traceability के साथ।

आज़माएँ: Markdown को PDF में बदलें

अच्छी report में क्या होता है

ऊपर की सूचियाँ बताती हैं कि report क्या cover करती है; पेश करने का तरीका तय करता है कि कोई उस पर कदम उठाएगा या नहीं। Template कोई भी हो, हर draft को इन बिंदुओं पर जाँचें।

Identification और scope: product, build, test level या cycle, environment, period और data लेने का समय।
सबसे पहले headline: एक line में overall status और उसकी वजह, और कोई ज़रूरी फ़ैसला। On track, at risk और off track जैसे status शब्दों की परिभाषा एक बार दें।
Plan के मुक़ाबले numbers: "80 planned में से 58", "58 run" नहीं। Passed, failed, blocked और not run अलग-अलग दिखाएँ; executed tests का pass rate उन tests के बारे में कुछ नहीं बताता जो कभी चले ही नहीं।
Feature, requirement या risk level के हिसाब से progress, ताकि बिना टेस्ट हुआ high-risk हिस्सा अच्छे total में न छिप सके।
हर Blocker या Critical defect अपनी ID, असर और owner के साथ नाम से; बाक़ी severity के हिसाब से counts।
Impediments और risks, owner और तारीख़ के साथ, या ईमानदारी से "पता नहीं", और कोई workaround हो तो वह भी।
पहले तथ्य, फिर आपका आकलन और सुझाव, साफ़ तौर पर आपकी राय के रूप में, और पिछली report के बाद का trend।

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

Worked example: कमज़ोर progress report को दोबारा लिखना

एक clinic booking app, release 2.4, दस दिन के system test cycle में है। Day 6 पर tester का product owner को पहला draft था: "Executed 58 tests, 52 passed, 90% pass rate. 9 bugs open. Some tests blocked. Testing continues." हर वाक्य सच है, फिर भी कोई इस पर कदम नहीं उठा सकता: 58 कितनों में से, कौन-से bugs मायने रखते हैं, क्या blocked है और कब तक, क्या तारीख़ ख़तरे में है?

नीचे का rewrite वही data और tester के पास पहले से मौजूद जानकारी इस्तेमाल करता है। यह progress report के लिए syllabus की सूची का हर item cover करता है, और साफ़ decision request वही है जिसे glossary की परिभाषा "alternatives requiring a decision" कहती है; identification line टीमों की आम practice है जो ऊपर से जोड़ी गई है।

Clinic booking app की day 6 progress report, हिस्सा-दर-हिस्सा: identification, period, status headline, plan के मुक़ाबले metrics, defects, impediment, नया risk, माँगा गया फ़ैसला और अगले कदम।

दोबारा लिखी गई progress report

भाग 1:1TEST PROGRESS REPORT · Clinic Booking 2.4 · System test, cycle 1
भाग 2:2Period: day 6 of 10 · data as of 28 Sep, 17:00 · build rc3 on staging
भाग 3:3Status: AT RISK. A Critical defect and a blocked SMS sandbox threaten
        sign-off on 4 Oct. Decision needed by 30 Sep (see below).

भाग 4:4Area                 Plan  Run  Pass  Fail  Blocked  Not run
Booking & payment      32   30    29     1        0        2
Rescheduling           18   12     8     4        2        4
SMS reminders          14    0     0     0        6        8
Profile & settings     16   16    15     1        0        0
Total                  80   58    52     6        8       14

भाग 5:5Open defects: Blocker 0 · Critical 1 · Major 3 · Minor 5
  CB-412 Critical: rescheduling keeps the old slot booked;
  blocks 2 tests; owner: backend team; fix expected 30 Sep
भाग 6:6Impediment: SMS provider sandbox down since 24 Sep; blocks 6 tests;
  owner: DevOps; no restore date yet; workaround needs a decision (below)
भाग 7:7New risk: if the CB-412 fix arrives after 30 Sep, regression cannot
  finish before sign-off

भाग 8:8Decision needed by 30 Sep: test SMS reminders with the live provider
  and staff phone numbers, or move sign-off to 6 Oct
भाग 9:9Next: retest CB-412, finish rescheduling, full regression on day 9

1IdentificationReport का प्रकार, product, release, test level और cycle, ताकि यह किसी दूसरी report से न मिल जाए।टीम practice
2Testing period और dataDay 6 of 10, data लेने का समय, और वह build व environment जिस पर यह लागू है।
3Status: progress और deviationएक status शब्द, उसकी वजह, ख़तरे में पड़ी तारीख़, और फ़ैसले की ओर इशारा।
4Plan के मुक़ाबले test metricsArea के हिसाब से planned, run, passed, failed, blocked और not run: 90% pass rate अब भी दिखता है, और untested SMS हिस्सा भी।run 58/80 · passed 52/58 = 90%
5DefectsSeverity के हिसाब से गिने गए defect metrics; अकेला Critical defect अपने असर, उससे blocked tests, owner और fix की तारीख़ के साथ।
6Impediment और workaroundक्या blocked है, कब से और owner कौन है, ईमानदार "restore की अभी कोई तारीख़ नहीं", और वह workaround जिस पर फ़ैसला चाहिए।
7नए और बदले हुए risksक्या अब भी गलत हो सकता है, होने से पहले लिखा हुआ।
8माँगा गया फ़ैसलाएक deadline और दो ठोस विकल्प जिनमें से product owner चुन सकता है: फ़ैसला माँगने वाले alternatives।ISTQB glossary
9अगले period के लिए planned testingआगे क्या होगा, ताकि पाठक जाने कि अगली report में क्या होगा।

Parts 2–7 और 9 वह सामग्री हैं जो CTFL v4.0 syllabus test progress report के लिए बताता है (parts 4 और 5 उसके test metrics हैं); part 8 ISTQB glossary की परिभाषा से आता है; part 1 टीमों की आम practice है।

90% अब भी है (58 executed में से 52), लेकिन table वह दिखाती है जो यह छिपा रहा था: SMS reminder का एक भी test नहीं चला और rescheduling पीछे है।
सिर्फ़ release के लिए ख़तरा बना defect नाम और owner के साथ लिखा है; बाक़ी आठ counts हैं।
Impediment का owner है और ईमानदार "restore की अभी कोई तारीख़ नहीं" है; उसके इकलौते workaround को मंज़ूरी चाहिए, इसलिए वही deadline और दो विकल्पों वाला फ़ैसला बन गया है।

पाठ संस्करण

TEST PROGRESS REPORT · Clinic Booking 2.4 · System test, cycle 1
Period: day 6 of 10 · data as of 28 Sep, 17:00 · build rc3 on staging
Status: AT RISK. A Critical defect and a blocked SMS sandbox threaten
        sign-off on 4 Oct. Decision needed by 30 Sep (see below).

Area                 Plan  Run  Pass  Fail  Blocked  Not run
Booking & payment      32   30    29     1        0        2
Rescheduling           18   12     8     4        2        4
SMS reminders          14    0     0     0        6        8
Profile & settings     16   16    15     1        0        0
Total                  80   58    52     6        8       14

Open defects: Blocker 0 · Critical 1 · Major 3 · Minor 5
  CB-412 Critical: rescheduling keeps the old slot booked;
  blocks 2 tests; owner: backend team; fix expected 30 Sep
Impediment: SMS provider sandbox down since 24 Sep; blocks 6 tests;
  owner: DevOps; no restore date yet; workaround needs a decision (below)
New risk: if the CB-412 fix arrives after 30 Sep, regression cannot
  finish before sign-off

Decision needed by 30 Sep: test SMS reminders with the live provider
  and staff phone numbers, or move sign-off to 6 Oct
Next: retest CB-412, finish rescheduling, full regression on day 9

आज़माएँ: Markdown फ़ॉर्मेटर

आम गलतियाँ

Raw counts बताना: "58 tests executed" का "80 planned में से" और blocked व not-run tests के बिना ज़्यादा मतलब नहीं।
Executed tests के pass rate से शुरुआत करना, जबकि एक पूरा high-risk हिस्सा टेस्ट ही नहीं हुआ।
हर audience को वही detailed report भेजना, जिससे sponsor वह एक फ़ैसला चूक जाता है जो उसे लेना है।
बुरी ख़बर को नरम करना ("थोड़ी देरी") या scheduled report तक रोके रखना, बजाय blocker को उसी दिन उठाने के।
तथ्य और राय को मिला देना, या status का रंग देना पर उसका मतलब न बताना।
Completion report याददाश्त से लिखना, बजाय progress reports और exit criteria से बनाने के।

QA का नज़रिया

Reporting test planning के समय तय करें: किसे क्या मिलेगा, कितनी बार, किस channel से, और executed, blocked और done की साझा परिभाषाएँ। Test plan में लिखी होने पर reports routine बनती हैं, हर बार नई जुगाड़ नहीं।

भेजने से पहले report को उसके पाठक की तरह पढ़ें: क्या वह दस सेकंड में समझ सकता है कि चिंता करनी है या नहीं, हर number को किसी तय समय पर test management tool या defect tracker तक trace कर सकता है, और फ़ैसले का जवाब वैसे ही दे सकता है जैसे वह लिखा है? फिर जवाब दर्ज करें, किसने और कब फ़ैसला किया: completion report को ये accepted risks के रूप में चाहिए होंगे।

अभ्यास

Raw test data से progress report लिखें

आपका काम

आप एक web shop के returns और refunds feature को टेस्ट कर रहे हैं। नीचे 5 दिन के system test cycle के day 4 के अंत का raw data है। Product owner के लिए progress report लिखें, और developers के chat के लिए दो-तीन lines का update।

फिर लिखें कि test completion report को किन चीज़ों की ज़रूरत होगी जो इस data में अभी नहीं हैं।

सामग्री

Feature: Returns & refunds, web shop 5.1 · system test, day 4 of 5
Data as of 15 Oct, 16:00 · build 5.1.0-rc2 on staging
Cycle ends 18 Oct · release planned 19 Oct

Planned: 60   Executed: 41   Passed: 37   Failed: 4
Blocked: 5    (refund to card: payment sandbox rejects test cards)
Not run: 14   (9 partial-refund tests, 5 return-label tests)

Open defects
  RF-88  Critical  Refund is issued twice when the user double-clicks
  RF-91  Major     Return label shows the wrong warehouse address
  RF-95  Minor     Typo on the confirmation page
  RF-97  Minor     Date picker accepts a return date in the past

Payment sandbox: vendor ticket open, no restore date given

चरण

Plan के मुक़ाबले progress और pass rate निकालें, blocked और not-run tests को सामने रखते हुए।
Overall status तय करें और उसकी वजह के साथ एक line की headline लिखें।
Release के लिए ख़तरा बना defect, impediment और उसका owner, और ज़रूरी फ़ैसला लिखें।
वही तथ्य developers के लिए दोबारा लिखें, फिर completion report के items की सूची बनाएँ।

मॉडल उत्तर दिखाएँ

मॉडल उत्तर

Numbers: 60 planned tests में से 41 executed (68%); 37 passed और 4 failed, यानी 90% pass rate। लेकिन 19 tests (32%) नहीं चले: 5 blocked और 14 अभी not run, जिनमें सभी 9 partial-refund tests हैं। Status: at risk, और सिर्फ़ एक दिन बचा है।

Product owner के लिए: "Returns & refunds 5.1, day 4 of 5 (15 Oct 16:00, staging पर rc2)। AT RISK: refund to card untested, Critical refund defect खुला; 18 Oct 12:00 तक फ़ैसला चाहिए। 60 में से 41 चले: 37 passed, 4 failed; 5 blocked, 14 not run। Defects: Critical 1, Major 1, Minor 2। RF-88: double click से refund दो बार जाता है, यानी हर बार पैसा जाता है; owner और fix की तारीख़ अभी confirm होनी है। Impediment: payment sandbox test cards reject करता है; vendor ticket खुला, कोई तारीख़ नहीं। फ़ैसला: cycle बढ़ाएँ और release आगे करें, या refund to card untested रखते हुए release करें। मेरा सुझाव: दोनों हालात में RF-88 खुला रहते release नहीं। आगे: partial refunds, labels, RF-88 का retest।"

Developers के लिए: "Day 4: 41/60 चले, 4 failed। RF-88 (double-click पर दो बार refund) release risk है, कृपया इसे पहले लें; RF-91 में warehouse address गलत है। Refund to card के 5 tests payment sandbox की वजह से blocked हैं। RF-88 staging पर आए तो बताएँ।"

Completion report के लिए अभी बाक़ी: exit criteria और हर एक पूरा हुआ या नहीं; plan से deviations; पूरे cycle के final metrics; impediments और workarounds; जो defects fix नहीं हुए और unmitigated risks, और उन्हें किसने स्वीकार किया; lessons learned, जैसे cycle शुरू होने से पहले third-party sandboxes की जाँच करना।

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

क्या test report और bug report एक ही हैं?

नहीं। Bug report (defect report) एक defect का वर्णन करती है ताकि उसे reproduce और fix किया जा सके। Test report पूरी testing का सारांश देती है, progress, metrics, risks और खुले defects समेत, उन लोगों के लिए जो फ़ैसले लेते हैं। अच्छी test report ज़रूरी defect reports का ज़िक्र उनकी IDs से करती है।

Test progress report कितनी बार भेजनी चाहिए?

जितनी बार पाठकों को फ़ैसले लेने के लिए चाहिए; syllabus उदाहरण के तौर पर रोज़ और हर हफ़्ते बताता है। टीम के अंदर अक्सर रोज़ और informal, दूसरे stakeholders के लिए हर हफ़्ते या हर sprint। जब कोई blocker या Critical defect सामने आए तो scheduled report का इंतज़ार न करें: उसी दिन उठाएँ।

Test completion report कौन लिखता है और कौन पढ़ता है?

आम तौर पर test manager या test lead लिखता है, या टीम में अलग lead न हो तो tester, पूरी टीम के input के साथ। यह उन लोगों के पास जाती है जो acceptance या release का फ़ैसला करते हैं, जैसे product owner, project manager या client, और testware के साथ रखी जाती है ताकि आगे की testing इससे सीख सके। Test completion और closure वाला lesson इसके आसपास की activities समझाता है।

क्या test report को बताना चाहिए कि release करें या नहीं?

उसे जानकारी देनी चाहिए और, पूछे जाने पर, आपका आकलन, साफ़ तौर पर आपकी राय के रूप में। Release का फ़ैसला उन stakeholders का है जिनका business risk है; report यह पक्का करती है कि वे यह जानते हुए फ़ैसला करें कि क्या टेस्ट नहीं हुआ और क्या अब भी खुला है।

संदर्भ

ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
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 रिपोर्ट।
ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।

टूल्स

और गहराई से

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

इस topic से पहले

टेस्ट मॉनिटरिंग और टेस्ट कंट्रोल

टेस्ट रिपोर्टिंग

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

Test progress report और test completion report

वही तथ्य, अलग-अलग पाठक

अच्छी report में क्या होता है

Worked example: कमज़ोर progress report को दोबारा लिखना

आम गलतियाँ

QA का नज़रिया

अभ्यास

Raw test data से progress report लिखें

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

संदर्भ

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

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

Markdown फ़ॉर्मेटर

Markdown को PDF में बदलें

Requirements → टेस्ट केस

और गहराई से

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

इस topic से पहले

अगले topics

इस मॉड्यूल के दूसरे topics

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

Test progress report और test completion report

वही तथ्य, अलग-अलग पाठक

अच्छी report में क्या होता है

Worked example: कमज़ोर progress report को दोबारा लिखना

आम गलतियाँ

QA का नज़रिया

अभ्यास

Raw test data से progress report लिखें

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

संदर्भ

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

और गहराई से

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

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

इस topic से पहले

अगले topics

इस मॉड्यूल के दूसरे topics