Test Reporting

Why it matters

Information that does not reach someone who can act on it is wasted. A Critical defect buried in a spreadsheet, a blocked environment nobody escalated, or a 90% pass rate that hides an untested area all end the same way: a release ships with a risk nobody knowingly accepted, or a deadline slips without warning.

For the tester, reports build trust: facts kept apart from opinion and specific requests for decisions present testing as a source of information, not a gate that only says "not ready".

Test progress reports and test completion reports

A test progress report belongs to test monitoring and control. The ISTQB glossary describes it as a periodic report on the progress of test activities against a baseline, such as the test plan, together with risks and alternatives requiring a decision. It is produced on a regular rhythm (daily, weekly or per sprint) and must give enough information to change the schedule, resources or test plan when testing deviates from the plan or circumstances change. It answers: are we on track, what is in the way, and what needs a decision?

A test completion report is prepared during test completion, when a test level, cycle, iteration or project is finished. Built from the progress reports and other data of the whole stage, it evaluates testing and product quality against the test objectives and exit criteria, and informs later testing. It answers: what did we test, how good is the product, and what risk remains?

ISO/IEC/IEEE 29119-3 gives templates for both and calls the progress report a test status report; some teams, and older syllabi, call the completion report a test summary report.

• Progress report: the testing period; progress against the plan, with notable deviations; impediments and their workarounds; test metrics; new and changed risks; testing planned for the next period.
• Completion report: a test summary; an evaluation of testing and product quality against the test objectives and exit criteria; deviations from the plan in schedule, duration and effort; impediments and workarounds; metrics based on the progress reports; unmitigated risks and defects not fixed; lessons learned.

Same facts, different readers

The syllabus points out that different audiences need different information, and that the audience also sets formality and frequency: reporting inside the team is often frequent and informal, while the completion report follows a set template and is written once. Channels range from talking at the stand-up, a CI/CD dashboard, a task board or a burn-down chart (the work remaining, plotted day by day) to chat, email, a wiki page or a formal report; teams spread across locations or time zones often need more formal, written reporting.

Tailor the depth, never the facts: every reader gets the same numbers under the same definitions.

• Developers and the team, daily: failing and blocked tests, defect IDs with owners, environment problems.
• Product owner or project manager, weekly or per sprint, and at once when testing is blocked: progress by feature or risk, open defects by severity, impediments, decisions needed.
• Sponsor or senior management, per release, on one page: status in plain words, residual risks and what each option costs.
• Auditors or a regulated client, where they apply: a formal completion report on an agreed template, with traceability from requirements to results.

Try it: Markdown to PDF

What a good report contains

The lists above say what a report covers; presentation decides whether anyone acts on it. Whatever your template, check each draft against these points.

• Identification and scope: product, build, test level or cycle, environment, period and the time the data was taken.
• A headline first: the overall status in one line with its reason, and any decision needed. Define status words such as on track, at risk and off track once.
• Numbers against the plan: "58 of 80 planned", not "58 run". Show passed, failed, blocked and not run separately; a pass rate of executed tests says nothing about tests that never ran.
• Progress by feature, requirement or risk level, so an untested high-risk area cannot hide inside a good total.
• Every Blocker or Critical defect named with its ID, impact and owner; the rest as counts by severity.
• Impediments and risks with an owner, a date or an honest "unknown", and any workaround.
• Facts first, then your assessment and recommendation, labelled as yours, and the trend since the last report.

Try it: Percentage Calculator Try it: Requirements → Test Cases

Worked example: rewriting a weak progress report

A clinic booking app, release 2.4, is in a ten-day system test cycle. On day 6 the tester's first draft to the product owner read: "Executed 58 tests, 52 passed, 90% pass rate. 9 bugs open. Some tests blocked. Testing continues." Every sentence is true, yet nobody can act on it: 58 out of how many, which bugs matter, what is blocked and until when, is the date at risk?

The rewrite below uses the same data plus what the tester already knew. It covers every item the syllabus lists for a progress report, and the explicit decision request is the "alternatives requiring a decision" from the glossary definition; the identification line is common team practice on top.

Part 1:1TEST PROGRESS REPORT · Clinic Booking 2.4 · System test, cycle 1
Part 2:2Period: day 6 of 10 · data as of 28 Sep, 17:00 · build rc3 on staging
Part 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).

Part 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

Part 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
Part 6:6Impediment: SMS provider sandbox down since 24 Sep; blocks 6 tests;
  owner: DevOps; no restore date yet; workaround needs a decision (below)
Part 7:7New risk: if the CB-412 fix arrives after 30 Sep, regression cannot
  finish before sign-off

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

• The 90% is still there (52 of 58 executed), but the table shows what it hid: no SMS reminder test has run and rescheduling is behind.
• Only the defect that threatens the release is named, with its owner; the other eight are counts.
• The impediment has an owner and an honest "no restore date yet"; its only workaround needs approval, so it becomes the decision, with a deadline and two options.

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

Try it: Markdown Formatter

Frequently asked questions

References

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• ISO/IEC/IEEE 29119-3:2021 — Software and systems engineering — Software testing — Part 3: Test documentationISO/IEC/IEEE · 2021Templates and content for test documentation — test policy, strategy, plan, status and completion reports, incident reports.
• ISTQB GlossaryISTQBThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.