Writing a release sign-off QA can defend

A release goes out. Two days later, something breaks in production. Someone asks: "Didn't QA sign off on this?"

If your sign-off was one line — "QA approved" — you have no answer. If your sign-off was a clear report of what was tested and what was not, you have a complete answer, and the conversation moves to the real question: was the risk decision right?

That is the whole purpose of a sign-off. It is not a guarantee. It is a risk report.

Short version

• A sign-off says what was tested, what was not, and what risks remain.
• It never promises "no bugs". Nobody can promise that.
• Known issues go in, with severity and workarounds.
• The go/no-go decision belongs to the release owner, informed by your report.
• Keep it to one page. Nobody reads page two.

What a sign-off is, and is not

A sign-off is QA's professional summary at the moment of release. It answers four questions:

1. What did we test?
2. What did we not test, and why?
3. What problems do we know about?
4. What is our overall risk assessment?

It is not a promise that the release is bug-free. Testing can only show the presence of bugs, never their absence. Any sign-off worded as a guarantee is a trap for the person signing it.

It is also not the go/no-go decision itself. QA reports risk; the release owner decides whether to accept it. Keeping those roles separate protects everyone — especially you.

The template

RELEASE SIGN-OFF — v4.8.0
Date: 07 May 2026 · Prepared by: <name> · Build: 4.8.0-rc2

1. SCOPE TESTED
- Checkout redesign (full regression + exploratory, 2 sessions)
- New CSV export (functional + boundary testing)
- Payment provider upgrade (smoke on all 4 card types)

2. NOT TESTED / PARTIAL
- Safari on iOS: smoke only (no device available this sprint)
- Load behaviour above 200 concurrent users: not tested
- Localised UI (DE, FR): spot checks only

3. RESULTS
- 142 test cases run: 136 passed, 6 failed (4 fixed and retested, 2 deferred)
- 3 exploratory sessions: 9 bugs found, 7 fixed, 2 deferred

4. KNOWN ISSUES SHIPPING IN THIS RELEASE
- [S3] Export loses column order on re-import (BUG-1204). Workaround: manual reorder.
- [S4] Tooltip flickers on Firefox (BUG-1198). No workaround; cosmetic.

5. RISK STATEMENT
Overall risk: LOW-MEDIUM.
Highest residual risk: iOS Safari checkout, tested at smoke level only.
Recommendation: release, with iOS checkout monitored for 48h after deploy.

6. SIGN-OFF
QA: <name> · Release owner decision: GO / NO-GO

Every section earns its place. Section 2 is the one most teams skip, and it is the one that protects you most.

Writing the "not tested" section honestly

This section feels dangerous to write. It is the opposite.

If you hide a gap and it breaks, you own the failure. If you declare a gap and it breaks, the team owned the risk together, with open eyes. Declared gaps also get resourced — the iOS device that "was not available this sprint" tends to appear once it shows up in three sign-offs in a row.

Write each gap with a reason and a level:

Safari on iOS: smoke only — no test device available this sprint.

"Smoke only", "spot checks", "not tested" — pick honest labels and use them consistently.

The known issues list

Every release ships with known bugs. That is normal. What matters is that they are chosen, not discovered later.

For each known issue include:

• Severity, using your team's scale
• The ticket ID, so nobody has to search
• The workaround, if one exists
• Who agreed to defer it

That last item quietly matters. "Deferred by product owner on 06 May" turns a future argument into a recorded decision.

If a known issue would embarrass the company on the front page — data loss, money, security, privacy — it does not belong on this list. It belongs in a conversation before release. The list is for accepted imperfections, not buried emergencies.

The risk statement

Two or three sentences, in plain words. It is the only part executives read, so write it for them.

Overall risk: LOW-MEDIUM. The checkout flow was fully regression tested and is solid. The main residual risk is iOS Safari, which received only smoke coverage. Recommend releasing with monitoring on checkout conversion for 48 hours.

Notice the shape: overall level, why, the biggest remaining risk, and a recommendation. Avoid both false confidence ("everything is fine") and vague fear ("there could be issues"). Name the specific risk and its size.

When you cannot sign off

Sometimes the honest answer is "not ready". Say it with the same structure — facts, not feelings:

Recommendation: NO-GO. Two S2 defects in payment capture remain open (BUG-1210, BUG-1213), and regression on refunds is 40% complete. Earliest realistic sign-off: 10 May, if fixes land by 08 May.

A no-go with a date and conditions is a plan. A no-go without one is just an argument.

And if the release owner decides to ship anyway? That is their call to make — risk acceptance is their job. Your report recorded the risk; you have done yours. Update the sign-off with one line: "Released with open items above, accepted by ."

Making the evidence easy to check

A sign-off is only as strong as the records behind it. When someone asks "what exactly did you test on checkout?", you want links, not memory: the test run, the bug tickets, and the evidence inside them.

This is where consistent bug reports pay off twice. Tickets that carry their own screenshots, console logs, and environment details — captured automatically by tools like Crosscheck — make the deferred-issues list self-explanatory, and make the post-release "what did we know?" question answerable in minutes.

Frequently asked questions

Who should write the sign-off? The QA person or lead closest to the release. On small teams, whoever did most of the testing. It should be one author, not a committee document.

How long should it take? Fifteen to thirty minutes, if you kept notes during the cycle. If it takes hours, the problem is record-keeping during testing, not the sign-off itself.

Should sign-offs be stored somewhere? Yes — one folder or wiki page, one file per release, searchable. They are the team's memory of what was known at each release.

What if there is no time for a proper sign-off? A five-line version beats nothing: scope, gaps, known issues, risk level, recommendation. The structure matters more than the length.

Does a sign-off make QA responsible for production bugs? It does the opposite. It shows the state of knowledge at release time and who accepted which risks. The dangerous position is an undocumented "QA approved".