A test closure report is the sign-off document that formally ends a release's testing and records whether the evidence supports shipping. A complete test closure report has six sections: scope covered and excluded, execution summary, defect summary by severity, traceability coverage, exit criteria with waivers, and residual risk with sign-off. It exists to answer one question after the fact: does the evidence support releasing, and for anything that fell short, who accepted that and on what basis.
If an auditor, a client, or a release manager ever asked your team for one of these and what you handed back was "testing is done, ship it," this article gives you the fields that actually satisfy that ask, filled in with real numbers rather than a blank skeleton. It's for the QA engineer or SDET who has to produce this document, who's onboarding a junior and needs something more concrete than a definition, or who's being asked in an interview to name what belongs in one.
It is not for the QA lead deciding how much process a whole test strategy needs, an allocation question covered in our piece on test entry and exit criteria, and it's not for a team wondering whether the tests an AI assistant generated are testing anything real. This one is narrower: you ran a suite against a real release, and now you have to write down, in a way an auditor can reconstruct months later, what happened and what you decided to accept.
Test closure report template: the six sections
A closure report isn't the software testing life cycle's six phases restated with a form stapled on. It's the artifact that phase produces: six recurring fields, each a specific claim, not a heading to decorate with adjectives.
| Section | What belongs in it |
|---|---|
| Scope | What was tested, and explicitly what wasn't |
| Execution summary | Planned, executed, passed, and failed case counts |
| Defect summary | Defects found, fixed, and deferred, by severity |
| Traceability coverage | Share of requirements the executed tests reach |
| Exit criteria and waivers | Which criteria passed, which were waived, and why |
| Residual risk and sign-off | What risk remains, and who approved the release |
A test summary report covers one cycle, sprint, or phase; a test closure report covers the whole release, adding sign-off, waivers, and residual risk. IEEE 829, the software test documentation standard, formalized reports like these as named deliverables long before anyone called them closure reports. Several summary reports typically feed one closure report.
The counts on the right are just the four cycles added up. The three rows underneath the divider are the only part that could not have been carried over from a summary report.
Here's what all six look like filled in, as a worked test closure report example.
A filled test closure report example
Take a release we'll call 4.12.0, "Notification Preferences Rework." Three feature epics: per-channel digest frequency controls, an SMS opt-out flow with double confirmation, and pagination for the in-app notification center. 138 test cases were planned across the three epics, and all 138 were executed.
In scope: those three epics, plus regression across the existing email and push paths sharing delivery infrastructure with the new work. Explicitly not covered: legacy digest templates deprecated in this same release, and delivery under peak send volume, a load characteristic that belongs to the team's own load-testing pass, not this suite.
Left column: counts a run produced. Right column: judgments with a name on them.
Twenty-seven defects surfaced during execution. Here's how they split by severity and by outcome:
| Severity | Found | Fixed | Deferred |
|---|---|---|---|
| Critical | 2 | 2 | 0 |
| High | 6 | 5 | 1 |
| Medium | 11 | 9 | 2 |
| Low | 8 | 4 | 4 |
| Total | 27 | 20 | 7 |
For trending counts like these release over release, see defect density and leakage. Against the requirements traceability matrix for this release, the 138 executed cases trace to 36 of 40 in-scope requirements, 90%, and that gap matches the two items already named as out of scope: proof the gap is a decision, not an oversight. For what that percentage can hide, see test coverage metrics.
Exit criteria for this release, and whether each was met outright or waived:
| Criterion | Target | Measured | Status |
|---|---|---|---|
| Planned cases executed | 100% | 138 of 138 | Met |
| Critical defects open | 0 | 0 | Met |
| High-severity defects open | 0 | 1 deferred | Waived |
| p95 latency, peak send volume | ≤400ms | 620ms | Waived |
| Traceability coverage | ≥90% | 36 of 40 (90%) | Met |
Three of five criteria closed clean. The other two are why the next section exists.
What a waiver in a test closure report must record
The exit criteria table is where an auditor's eye lands first, but what separates a real closure report from theater is what a waived row actually says. "Deferred" by itself isn't a waiver, it's an unresolved question wearing a status label. An auditor can't reconstruct from that single word what was actually measured, who decided the gap was acceptable, whether the decision covers this release only or every release after it, or when someone is supposed to look again.
The waived latency row, written out so an auditor can reconstruct the decision.
The good version carries six fields, and none of them are optional:
| Field | Recorded as "deferred" | Recorded as a real waiver |
|---|---|---|
| Criterion | Not stated | p95 latency, peak send volume |
| Measured vs. target | Not stated | 620ms against a 400ms target |
| Accepted by | Not stated | VP of Engineering |
| Scope of acceptance | Not stated | This release only |
| Revisit condition | Not stated | Re-measured before next release |
| Tracking ticket | Not stated | NOTIF-2291 |
p95 latency under peak send volume is a load-testing measurement, not a functional one, and it isn't something Autonoma or any behavioral end-to-end tool measures. That number came from the team's own load-testing pass, run with a tool built for exactly that job, such as k6 or Gatling, and it belongs in the waiver because it's an exit criterion for this release, not because an E2E suite produced it.
A deferred defect is a waiver by another name: it's an admission that a known problem is shipping anyway, and it deserves the same six fields. The high-severity deferred defect here follows them with a different owner: duplicate SMS opt-out confirmations sent when a user toggles the preference twice within two seconds, accepted by the Engineering Manager for Notifications for this release only, revisited at the next sprint's triage, tracked as NOTIF-2214.
How Autonoma supplies the evidence half
Everything above the waiver table is evidence: scope, execution counts, defect counts by severity, coverage against the matrix. It's the half of the report that used to take someone most of a day to assemble by hand, running the suite, counting outcomes, cross-referencing a spreadsheet, and typing all of it up before anyone got to the interesting question, which is what to do about the rows that didn't pass cleanly.
That's the layer we built Autonoma to remove for the web end-to-end portion of a suite. Our agents read your codebase to plan test cases directly against your routes, components, and flows, run them against a live preview environment, and classify each result as a real defect, an agent error, or a plan mismatch as the run finishes rather than days later when someone gets around to triage. Every run publishes its own pass and fail counts and a coverage view against the cases it planned. Point that output at the traceability matrix your team already maintains, or at a results dashboard or an automated reporting pipeline that already ingests structured run data, and the top half of a closure report gets close to generated rather than typed, the moment a run finishes.
This is additive, not a replacement. Autonoma doesn't run the load-testing pass that produced the 620ms number above, doesn't own unit-level structural coverage, and doesn't write the sentence that says a high-severity defect is acceptable for one release. It supplies fresh, structured evidence for the behavioral end-to-end portion of the suite. The judgment calls in the bottom half of the report stay a human's to make and sign, same as they always were.
Which test closure report sections are generated and which are judged
Once evidence generates itself, the honest split in a closure report isn't "sections filled in" versus "sections left blank." It's generated versus judged. Scope covered, the execution summary, the defect counts by severity, and traceability coverage are all outputs of a run, and a dashboard or a reporting pipeline can produce every one of them the moment a suite finishes. Scope explicitly not covered, the waiver rationale for anything that missed its criterion, and the residual risk statement are not outputs of a run. They're a decision about what a team is choosing to accept, made by someone with the authority to accept it, and no amount of dashboard automation changes whose name goes on that call.
This artifact existed in the first place because summarizing results by hand was expensive: someone had to run the suite, count what happened, and write it down before anyone could decide anything. Running the suite and counting what happened stopped being the expensive part. What's left, the part actually worth a person's time, is the part that says what the answer should be: which risk is acceptable, whose name is on that decision, and when it gets revisited. That's the judgment half, and it was the only half that was ever the real point of a closure report.
For release 4.12.0: the execution summary (138 of 138), the defect table, and the 90% traceability figure could all have been produced the moment the suite finished, no different from a build log. The judgment side is what's left, and it's short and specific rather than a general assurance: a residual risk statement naming the one known duplicate-confirmation defect deferred to next sprint's triage, the peak-send-volume behavior accepted pending a separate load-testing result, and the decision to leave legacy digest templates out of scope. None of that generates itself, because generating it would mean generating the judgment, and judgment isn't a category of automation.
If you're producing one of these today, start from the six-section table above and fill in real values rather than shipping the blank skeleton most templates hand you; a filled report with a two-line waiver beats a clean skeleton every time someone actually reads it during an audit. If your suite already runs against a live preview environment, wiring that run's output straight into the evidence half of the report is worth doing before your next release, whether that's through Autonoma or whatever already produces your structured results today. Either way, the judgment half is where your attention belongs, because it's the one part nothing generates for you.
Frequently Asked Questions
A test closure report is the document that formally ends a test cycle or release's testing activity. It records what was covered and what was explicitly not covered, how many defects were found, fixed, and deferred, how much of the requirements traceability matrix the executed tests reached, which exit criteria were met or waived, and the residual risk the team is accepting by releasing. It exists so someone reviewing the release later, an auditor, a new team member, or the team itself, can reconstruct exactly what the evidence supported and what was a judgment call.
At minimum: the scope tested and the scope explicitly excluded, a test execution summary with planned, run, passed, and failed counts, a defect summary broken down by severity and by outcome (fixed versus deferred), coverage against the requirements traceability matrix, the status of each exit criterion including any that were waived, a rationale for each waiver naming the accepted gap, who accepted it, the scope and duration of that acceptance, and the tracking ticket, and a residual risk statement summarizing what could still go wrong after release.
A test summary report is typically produced at the end of a test cycle, sprint, or phase, and describes what happened during that specific window: cases run, defects logged, and current status. A test closure report is produced at the end of a release or project's testing and is a formal sign-off document: it states whether exit criteria were met, documents any waivers with their rationale, and records residual risk before the release ships. In practice, several test summary reports across a release's life often feed into the one closure report that ends it.
It varies by organization, but the pattern is consistent: the QA lead or test manager confirms the evidence is accurate and complete, the accepting owner named in each waiver signs off on that specific accepted gap, and a release manager or engineering leader gives final approval to ship given everything documented. On smaller teams, one person may hold more than one of those roles, but the waiver-level acceptance should still be attributed to a specific named role rather than the report as a whole.
Residual risk is the risk that remains after testing and defect triage decisions are made, and it's what a test closure report's final section should state plainly rather than imply. It comes from three sources: functionality explicitly not tested, defects found but deferred rather than fixed, and exit criteria that were waived rather than met. A residual risk statement names these specifically, rather than asserting the release is low-risk in general, because a vague reassurance is exactly what a real incident later proves wrong.
Yes, for the behavioral end-to-end portion of a suite, and it produces them the moment a run finishes rather than after someone spends a day collating them. Autonoma's agents plan test cases from your codebase, run them against a live preview environment, and classify each result as a real defect, an agent error, or a plan mismatch, which is exactly what the execution summary, the defect counts by severity, and the coverage view are assembled from. Point that output at a results dashboard or a reporting pipeline and the top half of the report arrives close to written. The bottom half stays deliberately human: the scope you chose not to cover, the rationale behind each waiver, the residual risk, and the name on the sign-off. Load and performance criteria, like the p95 latency target in this example, come from a dedicated load-testing tool, which is the right source for them.
