QA Process
Test Summary Report Template.
A test summary report is the end-of-cycle record of what was tested, what was found, and whether it's fit to ship. This is a copy-paste template with eight parts plus a completed example for a real feature release.
When to use it
Write one at the end of a test cycle or release — when you need to hand leadership a single, readable account of results, coverage, and open risk that backs the go / no-go decision.
Who uses it
Senior QA and leads who compile and present it, and the product, engineering, and management readers who use it to judge release readiness without reading every test result.
On this page8 sections
WHAT IS A TEST SUMMARY REPORT
A test summary report is the document that closes a test cycle. It pulls the cycle's results into one place — what was in scope, how much ran and passed, what defects were found, how well the scope was covered, and what risk remains — and ends with a clear recommendation on shipping.
It's a summary, not a data dump. Anyone should be able to read it in a few minutes and know whether the release is in good shape, where the risk sits, and what's still open. The detail lives in the test management tool; the report tells the story.
WHEN TO WRITE ONE
Write one at the end of every meaningful test cycle: a release, a major feature, or a full regression pass. It's the natural bookend to the test plan — the plan says what you intended to test, the summary says what actually happened.
On a large release it's also the evidence behind sign-off. Where the weekly status report keeps people informed during the cycle, the summary report is the considered, final account written once testing is done and the numbers are settled.
WHO READS IT
The primary readers are the people making the release decision: the product owner, the engineering lead, and whoever signs off. They read it to answer one question — is this safe to ship, and if not, why not? Lead with what they need.
It has a second life as a record. Weeks later, when someone asks what was tested in v2.4 or why a known issue shipped, the summary report is the answer. Write it so it still makes sense to someone who wasn't in the cycle.
WHAT TO INCLUDE
Eight parts cover a complete picture without bloating the report. Each earns its place by answering a question the reader will otherwise ask.
The eight parts
Testing scope — what was tested and, just as important, what wasn't, so coverage is read in context.
Execution summary — cases planned, run, passed, failed, and blocked: the headline numbers.
Defect summary — defects by severity, how many fixed and verified, how many still open.
Coverage summary — how thoroughly the scope was covered, by feature, risk, automation, and platform.
Risks — the quality risks being carried, with likelihood, impact, and mitigation.
Outstanding issues — open defects and unfinished testing, each with an owner and a plan.
Recommendation — approved, approved with known risks, or not approved, with reasoning.
Lessons learned — what to keep doing and what to change next cycle.
THE TEMPLATE
# Test summary report: <release / cycle>
## Testing scope
What was in scope for this cycle — features, platforms, test types — and what was explicitly out.
## Execution summary
Cases planned, run, passed, failed, blocked. The headline numbers for the cycle.
## Defect summary
Defects found by severity, how many are fixed/verified, and how many remain open.
## Coverage summary
How thoroughly the scope was tested — by feature, risk, automation, and platform.
## Risks
Quality risks being carried, with their likelihood, impact, and any mitigation.
## Outstanding issues
Open defects and unfinished testing, each with an owner and a plan.
## Recommendation
Approved / Approved with known risks / Not approved — with a sentence of reasoning.
## Lessons learned
What to keep doing and what to change next cycle.
# Test summary report: Storefront v2.4 (guest checkout)
## Testing scope
Guest checkout end to end — cart, address entry, card / Apple Pay / PayPal, and the
confirmation email — on Chrome, Safari, and mobile Safari, plus a logged-in checkout
regression pass. Out of scope: the redesigned account area (ships in 2.5).
## Execution summary
142 cases planned · 142 run · 138 passed · 0 failed · 4 blocked (3DS sandbox flakiness,
all retried green). Functional testing complete; regression 100% pass.
## Defect summary
9 defects raised this cycle: 1 Critical, 2 High, 4 Medium, 2 Low. All Critical and High
fixed and verified. 2 Medium remain open (BUG-418 email VAT line, BUG-431 PayPal
slow-network spinner), both with workarounds.
## Coverage summary
All in-scope guest-checkout flows covered on the three target browsers; high-risk payment
paths got deep coverage including negative and decline cases. Automation covers the core
happy paths and 86 regression cases; the receipt-email check remains manual.
## Risks
On very slow networks the PayPal redirect shows a long spinner (BUG-431). Likelihood low,
impact cosmetic — the payment still completes. Mitigation: retry guidance documented for
support; fix committed for 2.4.1.
## Outstanding issues
BUG-418 (VAT line missing on confirmation email) — owner: payments team, fix in 2.4.1.
BUG-431 (PayPal slow-network spinner) — owner: web team, fix in 2.4.1. No open Critical/High.
## Recommendation
Approved with known risks — exit criteria met, no open Critical/High, only two documented
Medium defects with workarounds and committed fixes for 2.4.1.
## Lessons learned
Keep: starting the cycle from a green environment readiness check caught the bad deploy early.
Change: automate the receipt-email verification so it stops being the one manual gap, and
get the payments sandbox on a health check after two days of mid-cycle outages.
EXAMPLE COMPLETED REPORT
Read the completed Storefront v2.4 report above as a release decision in miniature. The scope is bounded (guest checkout on three browsers, account area explicitly out), the execution numbers are clean (142 run, 0 failed, blockers explained), and the defect summary resolves every Critical and High while naming the two Medium defects that stay open.
Because each section is specific, the recommendation writes itself. Exit criteria met, no open Critical/High, two documented Medium defects with workarounds and committed 2.4.1 fixes — that's precisely "approved with known risks", and the report shows its working rather than just asserting the verdict. The lessons-learned section then turns the cycle's pain (a bad deploy, a flaky sandbox) into concrete changes, so the next report is better than this one.
COMMON MISTAKES
Reporting raw numbers with no verdict.
A wall of pass/fail counts isn't a summary. Always end with a clear recommendation the reader can act on.
Hiding open risk to make the cycle look clean.
Name every outstanding defect and risk. A summary that omits them just moves the surprise to production.
Confusing it with the weekly status report.
The weekly report tracks progress mid-cycle; the summary is the final, considered account written once testing is done.
Skipping coverage and only reporting defects.
Zero defects with thin coverage isn't good news. State how thoroughly the scope was tested, not just what broke.
Dropping lessons learned.
The cheapest improvement you'll ever make is writing down what to change. Without it, the same problems recur every cycle.