Release & Reporting

1 The Hook

It is the day before the Tūāpapa portal goes live to 180,000 members. You have run your regression plan against build 1.1. Most things pass. The 5%-rate defect is fixed and confirmed. But two findings remain: the screen-reader announcement on the contributions confirmation is still missing (the keyboard fix landed, the announcement did not), and the balance display occasionally shows last night’s figure rather than today’s during the morning sync window.

Aroha puts it to you directly in the release meeting: “Are we good to go?” The whole room turns to you. The board wants this shipped; the date has been promised. The easy answer is “yep, looks fine.” The other easy answer is “no, there are open defects, we can’t ship.” Both are a tester ducking the actual job.

Your job is not to say yes or no and own the consequences alone. It is to lay out what you tested, what passed, what is still open, and what the risk of shipping each open item is — clearly enough that Aroha and the board can make an informed decision and own it. A good release recommendation does not hide the bad news to please the room, and it does not block the release out of caution. It tells the truth about risk and lets the accountable people decide with their eyes open.

2 The Rule

3 The Analogy

4 The Tester’s Real Role at a Release

It is worth being precise about what you are and are not accountable for, because new testers often get this wrong in both directions.

• You are accountable for: the completeness and honesty of the picture — what was tested, what was not, what passed, what is still open, and an evidence-based assessment of the risk of each open item.
• You are not accountable for: the business decision to ship or not. That sits with the product owner and, for something this size, the board. They weigh your risk picture against the commercial and regulatory context.
• You do give: a recommendation — go, no-go, or conditional go — with your reasoning. A recommendation is not a decision; it is your professional read, which they can accept or override.

Holding this line is what makes you trusted. If you quietly bless every release, your sign-off means nothing. If you block releases out of caution, you become an obstacle to route around. The respected tester is the one whose risk picture is always straight, whatever the room wants to hear.

5 Basing the Call on Evidence

Your recommendation is only as good as the evidence under it — and you have been building that evidence since Week 3. The release picture is assembled from your own artefacts:

• The run log: what was executed against build 1.1, with pass/fail/blocked counts — the raw coverage picture.
• The open defects: each remaining defect with its severity and a plain-language statement of what shipping it would mean for a member.
• The regression plan: what you re-tested and what you justified skipping, so the board can see the limits of what was checked.
• Untested or blocked areas: stated honestly — a gap you don’t mention is a risk the board accepted without knowing.

Every week of the capstone has been quietly building toward this moment. The clarifying questions, the test cases, the results, the defects, the regression plan — they all converge into the evidence base for one decision. A release recommendation with no evidence behind it is just an opinion in a meeting.

6 Go, No-Go, and the Conditional Go

The recommendation is rarely a flat yes or no. The most useful answer is often a conditional go — ship, but with named mitigations or follow-ups — because it lets the business hit the date without pretending the open items don’t exist.

The conditional go is where good testers earn their keep. It is not a fudge — it is a precise statement of “here is what makes shipping acceptable”, which gives the business a real option between blocking and shipping blind.

7 The Executive Summary

The board will not read your run log. They will read a half-page executive summary, and your recommendation lives or dies on whether it lands in two minutes. An executive summary is plain English, leads with the recommendation, and gives just enough evidence to justify it.

Notice the shape: recommendation first, then coverage, then the open risks in plain terms a board member understands, then the specific conditions, then an honest note of what was not tested. No jargon, no hidden bad news, and everything traceable to the evidence you built across the capstone.

8 Common Mistakes

9 Now You Try

Three graded exercises on the release call. Write your answer, run it for feedback from your test lead, then compare to the model answer.

This recommendation tells the board nothing they can decide on. Any three earn full marks.

1. The open items are hidden behind "a couple of little things, nothing major, I'm sure it'll be fine" — that downplays real risk (a missing screen-reader announcement is an accessibility-standard gap) and gives the board no way to weigh it. Each open item needs its severity and what shipping it means for a member.

2. No evidence — "most stuff passed" and "tested it pretty thoroughly" give no counts, no coverage, no statement of what was NOT tested. A recommendation with no evidence is just an opinion in a meeting.

3. It collapses recommendation into decision and offers no conditional option — "ship it" takes the decision rather than presenting risk for the board to own, and there is no conditional go with named mitigations, which is usually the right answer when small items are open.

The fix: lead with a clear recommendation (likely conditional go), state coverage with counts, list each open item with its member/regulator impact, and name specific conditions — in plain English, hiding nothing.

Recommendation: Conditional GO. Both previously critical defects are fixed and confirmed; the two remaining items are medium/low and can be shipped with mitigations.

Open item 1 — risk: The contributions confirmation is not announced by a screen reader, so members using one cannot confirm their rate change succeeded. This is an accessibility-standard gap (NZ Government Web Accessibility Standard) that excludes some members.
Open item 1 — condition (checkable): Screen-reader announcement implemented and re-tested with a screen reader, signed off, before 20 June 2026.

Open item 2 — risk: During the morning sync window the balance shows last night's figure, not today's. It is confusing but corrects itself once synced; the number is not wrong, just stale for a short window.
Open item 2 — condition (checkable): The balance is labelled "as at last night" during the sync window from day one, until the live-sync fix is shipped; ticket raised and scheduled.

Who decides: The product owner (Aroha) and the board make the go/no-go call; this is my recommendation and risk picture for them to weigh.

What makes this strong: a clear recommendation, each open item stated in member terms with its severity, conditions specific enough to verify (a date, a label, a sign-off), and an explicit note that the decision is the business's. The original hid the risk and took the decision.

Test summary — Tūāpapa member portal, build 1.1

Recommendation: Conditional GO.

What we tested: login, balance display, contribution-rate changes, contact details, and the two fixes from last sprint. 142 test cases run — 138 passed, 2 failed, 2 blocked. Both previously critical defects (an invalid contribution rate being accepted; the rate selector not being keyboard-accessible) are fixed and confirmed.

Open items and risk:
 - Screen-reader announcement missing on the contributions confirmation (medium): members using a screen reader cannot confirm their change succeeded — an accessibility-standard gap that excludes some members.
 - Balance shows last night's figure during the morning sync window (low/medium): confusing but self-correcting; the figure is not wrong, only briefly stale.

Conditions for go: (1) the screen-reader announcement is implemented and re-tested before 20 June 2026; (2) the balance is labelled "as at last night" during the sync window until the live-sync fix ships.

Not tested: performance at full member load (planned as a controlled post-launch check).

Evidence: run log for build 1.1, defect register, and regression plan attached. The go/no-go decision sits with the product owner and board; this is the test team's risk assessment and recommendation.

A strong summary leads with the recommendation, states coverage with honest counts, expresses risk in member/regulator terms, gives checkable conditions, admits what was not tested, and points to evidence — readable by a board member in two minutes.

10 Self-Check

Click each question to reveal the answer.

11 Interview Prep

Real questions asked in NZ QA interviews. Read the model answers, then practise your own version.