What Is a Test Report? Test Reporting Types, Template, and Example

What is a test report?

A test report is a document that summarizes what was tested, how the tests went, and which defects and risks remain open, so stakeholders can decide whether a build is ready to release. Test reporting is the ongoing work of collecting those results and sharing them as documents, dashboards, or alerts.

A test report is not the same as the raw output of a test run. Three documents get mixed up:

A test log like the one above tells you exactly which step failed and on which browser. It doesn't tell you whether the release is safe. That's the job of the report, which is built from many logs and a test execution report per run.

In the software testing life cycle, the final test report belongs to test cycle closure, the last stage after test execution. Progress reports appear earlier, while tests are still running. Both are part of test management.

Why test reports matter

• They support a decision. A release manager rarely reads 400 results. They need to know what passed, what's broken, what wasn't tested, and what the QA lead recommends.
• They make risk visible. An open critical defect or an untested payment flow is a business risk, not only a QA detail. The report puts it in front of the people who own that risk.
• They show progress against the plan. Comparing executed tests and exit criteria against the test plan shows whether testing is on track or slipping.
• They leave a record. Audits, regulated releases, and client handovers often need a signed-off document that shows what was tested and who accepted the risk.
• They improve the next cycle. Trends in flaky tests, escaped defects, and blocked environments show where the test process itself needs work.

Types of test reports

Teams commonly use 3 reports across a release. The names vary: IEEE 829-1998 called the end-of-cycle document a test summary report, while ISO/IEC/IEEE 29119-3 and the current ISTQB glossary call it a test completion report, and call the progress report a test status report. Many teams write a summary report at the end of each cycle and a final completion report at the end of the release, as in the table below.

A report can also be requested at any time, for example after a production incident or a major late change resets the risk picture.

Other reports teams use alongside these:

• Defect report: open and closed defects by severity, priority, and status, and how long they stay open. Not to be confused with a single bug report; see our bug report template.
• Test execution report: the results of one run or suite, covered in more detail under test result reports for automated runs below.
• Automation report: results from automated suites, usually per CI build.
• Re-run report: the final result of each test after automatic retries, so a test that failed once and passed on retry is counted once, with its retry recorded.
• Flaky test report: tests whose result flips between pass and fail without any code change. See how to handle flaky tests.
• Stale test report: tests that haven't run in a long time or that cover features that have changed, so the team can update or retire them.
• Traceability report: each requirement linked to its tests, results, and defects, usually as a traceability matrix.

You don't always need a formal document. During a sprint, a shared dashboard and a stand-up update often do the job. Keep the written summary report for release decisions, audits, and handovers.

What to include in a test report

A useful test report answers 10 questions. The examples come from the worked example further down.

Coverage is easier to report honestly when every test case is linked to a requirement. A traceability matrix gives you that link, whichever tool you use.

Test summary report template

A test summary report is a summary of the testing activities and results for a cycle or release, with an evaluation against the exit criteria agreed in the test plan. Copy the table below into your wiki, document, or spreadsheet. The right-hand column is filled in for the worked example.

How to fill it in: write the recommendation last but put it at the top when you share the report. Keep each cell to one or two lines and link out to the run results and defect list for detail. A progress report can drop the objectives, exit criteria, recommendation, and sign-off rows and add a "next steps" row instead.

Test report example: release 4.2, cycle 3 (regression)

All numbers below are illustrative. The release is the same online store release 4.2 used in our test plan example, so the exit criteria come straight from that plan.

Execution summary

Failure triage. Every one of the 27 failures was checked before it was counted as a product problem:

Defects raised

Exit criteria check (the 6 exit criteria copied from the test plan)

Recommendation: hold. Blocker: DEF-311 (critical). Fix DEF-311 and DEF-305, restore the payment sandbox, then run the 8 blocked payment cases and the full checkout and payment suites again in an extra cycle 4. The deferred gift card cases stay untested and move to release 4.3.

The same cycle for 3 audiences

The data stays the same. The length changes with the reader.

• Developers, in the team chat: "4.2 cycle 3 (regression): 398 of 412 run, 93.2% pass, 1 critical open (DEF-311, double charge on retry), 8 payment cases blocked by the sandbox."
• Product manager, in the sprint summary: 5 lines covering progress (96.6% executed), the top risk (DEF-311), what's blocked (payment sandbox), what moves to cycle 4 (re-runs and fixes), and what's deferred (gift card cases).
• Leadership, before the release decision: the filled template above, starting with the recommendation and the one risk that drives it.

Test report metrics and formulas

Pick the few metrics that support the decision in front of you. For a wider set, see our guide to test automation metrics.

One run on its own can mislead. A 93% pass rate is good news after 85% and bad news after 98%. Show the last 3 to 5 cycles side by side (illustrative values, 398 tests executed in each cycle):

Here the pass rate is improving, but the same 18 failures have shown up in every cycle since cycle 1. That's a stronger signal than any single pie chart of passed and failed tests.

Test reporting dashboards vs test reports

A dashboard and a report answer the same question at different speeds. A dashboard updates as new results come in; a report is a snapshot someone has read, explained, and signed.

Use a live dashboard for day-to-day test reporting. Keep a signed-off document when a decision needs a named owner: regulated releases, audits, and client handovers. A good QA dashboard shows:

• Pass and fail trend by build, not only the latest run
• Release readiness against the exit criteria
• Open defects by severity and priority
• Flaky and slow tests, kept separate from real failures
• Coverage per browser, OS, or device configuration
• Execution duration over time, so a slowing suite gets noticed

To get these views without building them by hand, use TestOps. Its Analytics & Trends, Release Health, and Live Monitor dashboards give quick summaries, and reports such as Test Runs Analysis, Defects Activity Analysis, and Requirement Coverage Analysis go deeper. The Release Health dashboard (also called Release Readiness) marks a release or sprint as Ready or At Risk against gates a Project Admin sets: a minimum requirement coverage, a minimum pass rate, and blocking-defect rules by priority and severity. Defect reports and defect rules need Jira or Azure DevOps connected.

You can export a dashboard or report to PDF or CSV or share it by link, and an automated run can email a PDF of its results when it finishes. Results uploaded from Katalon Studio, Playwright, Jest, Pytest, Robot Framework, and other frameworks are analyzed in one place.

If you're comparing options, see our roundup of test reporting tools.

Test result reports for automated runs

A test result report for an automated run pulls together logs, framework reports (often HTML or JUnit XML), screenshots, and run history. Reporting it honestly takes a few rules:

• Count each test once. If a test fails and then passes on retry, report the final result and note the retry, as a re-run report does.
• Separate flaky and quarantined tests from real failures. Otherwise one unstable test makes a healthy build look broken, and the team stops trusting red builds.
• Tag every failure by cause: product bug, test issue, environment, or test data. Environment noise shouldn't read as product risk.
• Report trends per pipeline, not only the latest build.

For per-run detail, see the automation test execution report and test execution report guides.

How to write a test report

1. Decide who reads it and what decision it supports. A release go or no-go needs a different report from a daily status update. In the example, the reader is the release manager deciding on 4.2.
2. Fix the scope and the exit criteria from the test plan. Copy the criteria as written, so you can't adjust the bar after the results come in. Release 4.2 has 6 exit criteria.
3. Collect results and triage every failure before counting. Sort failures into product bug, test issue, environment, and test data. In the example, only 16 of 27 failures were product bugs.
4. Calculate the metrics and compare them with the last 3 to 5 cycles. The 93.2% pass rate only means something next to 88.4% and 91.0%.
5. State the risks and the untested areas plainly. Name the blocked payment cases and the deferred gift card cases, and what each leaves uncovered.
6. Write the recommendation first, then the evidence, and get sign-off. "Hold until DEF-311 and DEF-305 are fixed" goes at the top; the tables go underneath.

Common test reporting mistakes and how to fix them

• Numbers with no analysis. A table of results isn't a report. Fix: start with the recommendation and the 1 to 3 findings that drive it.
• One snapshot, no trend. A single run hides whether quality is improving. Fix: show the last 3 to 5 cycles side by side.
• Treating every failure the same. Test issues and environment problems inflate the failure count. Fix: triage before you count, and report each cause separately.
• Hiding what wasn't tested. Blocked and deferred tests are untested scope. Fix: give "not tested and why" its own row.
• A pass rate with nothing to compare it to. 93% says little without a target or a previous cycle. Fix: check results against the exit criteria in the test plan.
• One report for every audience. Executives tend to skip 4 pages of tables; developers need the defect IDs. Fix: write the short version for each reader from the same data.
• A report that arrives after the decision. Fix: agree the report date with the release manager when you plan the cycle, and send progress reports before it.

Note what's improved since the last cycle too, such as fewer recurring failures or a shorter run. It helps the team see what's working and keep doing it. And be honest about the limits: a test report shows what was tested and what was found. It can't prove the software has no bugs, so state the residual risk alongside the recommendation, especially for areas like regression testing that were cut short.