L1Go deeper4 min read

The test summary report and release sign-off

What was tested, what was found, what is still open, and whether you would ship it. One page, written for people who will not read a second. Sign-off is a judgement you are putting your name to rather than a rubber stamp, and the wording matters on the day something goes wrong.

At the end of a hospital shift, the nurse going home briefs the nurse coming in.

It is short and it is specific. Who is stable, who is not, what changed in the last hour, what to watch. Nobody reads a five-page essay at handover, and nobody wants to hear how busy the shift was.

A test summary report is that handover. What was tested, what was found, what is still open, and whether you would ship it.

One page. Written for people who will not read a second one.

The four sections

What ran. Scope tested, build, environment, dates. Numbers where you have them.
What was found. Defects by severity, with the notable ones named. Not a dump of every ticket.
What is still open. Accepted failures, known gaps, anything deferred, each with who accepted it.
Recommendation. Ship, ship with these caveats, or hold, and the reason in one sentence.

Why you should care about this

Because this page is the only part of your month that senior people read.

They will not read the cycle log or the matrix. They will read four sections and a recommendation, and their impression of the whole release comes from it. A vague summary makes careful work look careless.

It also protects you. Say a feature shipped with a known caching bug that product accepted on the Wednesday. If that is written down with a name against it, the conversation after an incident is a review. If it is not, the conversation becomes about what testing missed.

How to write one in twenty minutes

Start from the plan. Scope, out-of-scope and exit criteria are already written. The summary reports against them, which is why the two documents belong together.
Pull the numbers from the cycle log. Cases run, passed, failed, and how long it took. The regression cycle produces all of it, so there is no new counting.
Name only the notable defects. Two or three, with one line each, written as in a bug report that gets fixed. Link the rest.
List the open items with owners. "Accepted by Sam on 3 September" is the phrase that makes this useful later.
State the gaps plainly. Anything untested, and why. For example, a story that landed on the last afternoon and got happy-path testing only.
Write the recommendation last, in one sentence. If you would not ship it, say so and say what would change your mind.
Keep it with the release record. A summary in somebody's email is not evidence, which is the argument for one place the release rests on.

"Tested and approved" is a sentence you cannot defend. "This is what I tested, this is what I found, and I would ship it" is one you can.

A complete one-page report

Same release as the plan and the cycle, so you can see the three documents fit together.

test-summary-gift-cards.md

TEST SUMMARY, GIFT CARDS
Build rc-2026-09-04.5   Environment staging   Tested 1 to 3 September
Author Priya N          Plan: gift-cards-test-plan.md

WHAT RAN
  84 regression cases, all run. 18 of them new gift-card cases.
  3 exploratory charters, 90 minutes each: partial redemption maths,
  refunds against gift-card orders, scheduled delivery timing.
  Automated: 214 unit, 46 API, 9 browser. All green on rc-2026-09-04.5.
  Not run: performance and load, per the plan.

WHAT WAS FOUND
  6 defects.
    critical  0
    high      2   both fixed and re-tested
              WB-1863 refund of a part-gift-card order showed 0.00
              WB-1864 partial redemption rounded the balance down by 1p
    medium    3   1 fixed, 2 accepted (below)
    low       1   accepted, CSV column order

  The 1p rounding defect was the most serious. It appeared only on order
  totals ending .49 or .99, so it would have reached customers.

WHAT IS STILL OPEN
  WB-1865  balance page shows a stale balance for up to 60 seconds after
           use. Caching. Accepted by Sam O on 2 September, in the release
           note.
  WB-1866  admin CSV export column order changed. Cosmetic. Accepted by
           Sam O on 3 September.
  Gap      card expiry is untested and out of scope. The field exists and
           is unused. Agreed with Sam O on 24 August.
  Gap      scheduled delivery has no monitoring on the cron worker
           (WB-1841). Happy path tested only.

EXIT CRITERIA
  every story's criteria checked and recorded              met
  zero open critical or high defects in scope              met
  money maths charter with no unexplained discrepancy      met
  regression pack run, failures triaged or accepted        met
  known gaps in the release note                           met

RECOMMENDATION
  Ship. The two high defects are fixed and re-tested, the open items are
  cosmetic or documented, and the money paths were the focus of both the
  automated and exploratory work. I would release this.

  Priya N, 3 September 2026, 16:20

Notice how little of that required new work. The scope came from the plan, the numbers from the cycle log, the accepted items from the triage meeting. Twenty minutes, because the record was kept as it happened rather than reconstructed at the end.

How to show you know it

A one-page summary for a real release. With a recommendation in your own words, not a template phrase.
An open item with a name and a date. It shows you record decisions rather than absorbing them.
A stated gap. "This was not tested, and here is why" is the line that separates a report from a reassurance.
A recommendation you once made against shipping. Rarer, and the strongest evidence that your sign-off means something.

Questions

How long should a test summary report be?

One page. If it runs longer, you are either listing every defect instead of linking them, or describing activity instead of reporting outcomes.

What is the difference between this and a test closure report?

Mostly the name. Some organisations use closure for a project ending and summary for a release. Both answer the same four questions, so use whichever word your team already uses.

Who signs off, me or the product owner?

You recommend, they decide. That split keeps the judgement with the person who tested and the accountability with the person who owns the release. Write both names on the page.

What if I am asked to sign off on something I am not comfortable with?

Report the facts and make the recommendation you actually believe, including the caveats. Then let the owner decide and record the decision. Your name is on the evidence and the recommendation, not on the outcome.