Release readiness people can actually read

Most release packs fail the same way: they list activity instead of risk. “200 cases executed” does not tell a Head of Engineering whether Friday’s ship is wise. It tells them the test team was busy. The handful that failed might be cosmetic or might all sit in the payment step, and the pack leaves the reader to work out which.

A release readiness note is the short document that goes to the people making the ship-or-wait call. I have written them for two-week sprints and monthly releases, on teams of five and programmes of more than forty, and the test of a good one never changes: someone outside the test team can read it and know what to do.

What a release readiness note is for

It supports one decision: do we ship this build, on this date, knowing what we know? Every line either helps the reader make that call or gets in the way. A test summary report answers a different question, which is what the test team did. That belongs in an audit trail, not in front of leadership on a Thursday afternoon.

Three readers matter and they want different things. The Head of Engineering wants to know whether the release is wise. Product wants to know what users will feel. The business owner wants to see what has been deferred and what it could cost.

What goes into a release readiness note

I write it as a short narrative in a fixed order, so a reader who stops after two lines still leaves with the call.

The order matters more than the headings. Most packs open with the numbers and close with the recommendation, or leave it out and let the meeting infer one. I put mine in the first line because it is the part I am most likely to be wrong about, and I want it challenged while there is still time to act.

The open section is held to the same standard as a UAT sign-off: each item says what the user will experience, why that is tolerable or not, who owns it and when it is looked at again.

How to report test coverage honestly

The verified section is where false confidence gets in. “Tested on mobile” can mean a physical phone in a tester’s hand or one automated run on a device farm, and the reader cannot tell which unless the note says.

On mobile and wearable work I call out device coverage explicitly: what ran on a farm and what ran on physical devices, the spread of OS versions, and which journeys were exercised by hand. A watch that pairs on a desk and a watch that syncs on a wrist halfway through a run are different claims. I go into why in Mobile QA beyond “run it on BrowserStack”.

Name the build. Name the environment and say plainly where it differs from production: a stubbed payment provider, a smaller data set, a feature flag that will only be switched on live. Known limitations go in ordinary language in the body of the note, where they will be read.

What was not tested gets its own line. If regression was scoped to what the release touched, as I describe in Regression strategy without paralysis, the note says which areas were left alone and why. An untested area that is written down is a risk someone can accept. One that is left out is a surprise with a date on it.

Where the numbers belong

Numbers still matter, as supporting evidence under a clear recommendation. Cases run, pass rate, open defects by severity: all of it goes at the bottom, linked, for the reader who wants to check my working. Put a number at the top and the release gets judged by the number.

The counting should also be cheap. When I automated JIRA reporting, the effort of producing reports fell by about 70%. That is the right way round: the dashboard produces the counts, and the time goes into the paragraph that says what they mean.

Objections to a one-page readiness note

The first objection is that one page undersells two weeks of work. But the reader is not grading effort, and a long pack gets skimmed for the colour at the top.

The second is that QA should report facts and leave the recommendation to others. I disagree. The decision belongs to Product and Engineering, and the note should say so. But the person who spent the sprint inside the build has a view, and withholding it makes the meeting guess.

The third is a request for a single status colour. Give it, with the sentence that explains it right beside it. Amber with a named condition is useful. Amber alone is a shrug.

Before sending, I hand the note to someone who is not a tester and give them three minutes. If they cannot tell me the call and the biggest open risk, I rewrite it. Clarity is part of quality.

A note written this way changes what the release meeting is about. People arrive having read the call, so the time goes on the open risks instead of on decoding a spreadsheet. And when something does go wrong after go-live, the record shows what was known, what was accepted and by whom.