QA Process
Release Sign-off Template.
Release sign-off is the recorded go / no-go decision that testing is done and the release meets its agreed bar. This is a copy-paste template plus a completed example and the four recommendations you can give.
When to use it
Use this at the end of a release cycle to turn your test plan's exit criteria into an explicit, recorded go / no-go everyone can stand behind — especially when shipping carries known risk or needs business acceptance.
Who uses it
QA leads who prepare and present the sign-off, and the product, engineering, and (where relevant) security or compliance owners who approve it.
On this page10 sections
WHAT IS RELEASE SIGN-OFF
Release sign-off is the formal decision that testing is complete and the release meets the quality bar the team agreed up front. It converts the test plan's exit criteria into a single recorded verdict: go, or no-go.
It is a record, not a rubber stamp. A good sign-off states what was tested, what's still open, and what risk is being accepted — so that if something surfaces in production, the decision and its context are written down, not reconstructed from memory.
WHO SIGNS OFF A RELEASE
Each approver signs for their own area: the QA lead for quality and test completeness, the product owner for business acceptance, and the engineering lead for technical readiness. On regulated or sensitive releases, security or compliance signs too.
Keep the list to people who can actually accept the risk. A sign-off with five names but no decision-maker is theatre; two or three accountable approvers is a decision.
QA SIGN-OFF VS BUSINESS SIGN-OFF
These are two different statements, and a release usually needs both.
QA sign-off
"Testing is complete and the quality bar is met." It's a statement about evidence: the planned tests ran, exit criteria are satisfied, and open defects are known and within threshold.
Business sign-off
"The business accepts shipping this, including its known risks and timing." QA can sign off on quality while the business still decides not to ship today — or to ship with accepted risk. They're separate calls.
RELEASE READINESS CHECKLIST
- All planned tests have been executed.
- No open Critical or High defects — or each is documented and accepted.
- The regression suite has passed.
- Exit criteria from the test plan are met.
- Known issues are documented with workarounds.
- Performance, security, and accessibility checks are complete or marked N/A.
- The tested build matches the build being released.
- A rollback plan is in place.
- All required approvers are available to sign off.
GO / NO-GO RECOMMENDATION
| Recommendation | When to use it |
|---|---|
| Approved for release | All exit criteria met; no open Critical/High; no carried risk. |
| Approved with known risks | Exit criteria met except documented, accepted risks that have workarounds. |
| Not approved for release | Exit criteria not met — open Critical/High or a failed key flow. |
| Blocked pending fixes | Can't decide yet — testing is incomplete or a blocker is unresolved. |
KNOWN ISSUES SECTION
Every release ships with some known issues; the sign-off is where you make them visible instead of hoping no one notices. List each with four things: what it is, who it affects, the workaround, and when it'll be fixed.
This list is what support, on-call, and the business rely on. A documented Medium defect with a workaround is a managed risk; the same defect undocumented is an outage waiting to surprise someone on Monday.
RISK ACCEPTANCE SECTION
Shipping with known risk is fine — shipping with unowned risk is not. When a release goes out with accepted issues, name who accepted each one and record it alongside the sign-off. That person is saying, on the record, "I understand this and I'm choosing to ship."
Risk acceptance is a decision, not a shrug. If no one will put their name to a risk, that's a signal the recommendation should be "not approved", not "approved with known risks".
THE TEMPLATE
# Release sign-off: <release name / version>
## Release version
The version or release name this sign-off covers.
## Release date
Planned go-live date.
## Environment tested
Where testing was performed (staging, pre-prod).
## Build number
The exact build / commit that was tested and is being signed off.
## Scope tested
The features and flows covered by this release's testing.
## Test summary
A short paragraph: what was tested and the overall outcome.
## Pass/fail counts
Cases run, passed, failed, blocked.
## Open defects
Count by severity, with links to anything still open.
## Known risks
Risks being carried into production and why they're acceptable.
## Regression status
Result of the regression suite (pass rate, anything skipped).
## Automation status
What automated coverage ran and its result.
## Performance status
Performance / load results against target, or N/A.
## Security status
Security checks performed, or N/A.
## Accessibility status
Accessibility checks performed, or N/A.
## Recommendation
Go / no-go — one of the four recommendations, with a sentence of reasoning.
## Approver names
Who is signing off (QA, product, engineering, compliance).
## Sign-off date
The date sign-off was given.
# Release sign-off: Storefront v2.4 (guest checkout)
## Release version
Storefront v2.4
## Release date
2026-06-19
## Environment tested
Staging and pre-prod (production-like data, Stripe sandbox)
## Build number
web-storefront 2.4.0 / checkout-service 2.4.1 (commit a1b9f3c)
## Scope tested
Guest checkout end to end: cart, address entry, card + Apple Pay + PayPal,
confirmation email, plus logged-in checkout regression.
## Test summary
All planned functional and regression testing is complete. Core guest-checkout
paths pass on every supported browser. Two non-blocking defects remain open;
both have workarounds and are scheduled for 2.4.1.
## Pass/fail counts
142 run · 138 passed · 0 failed · 4 blocked (3DS sandbox flakiness, retried green)
## Open defects
0 Critical · 0 High · 2 Medium (BUG-418 email VAT line, BUG-431 PayPal slow-network spinner)
## Known risks
On very slow networks, the PayPal redirect can show a long spinner (BUG-431). The
payment still completes; impact is cosmetic. Accepted for launch, fix in 2.4.1.
## Regression status
Logged-in checkout regression: 100% pass (Playwright, 86 cases).
## Automation status
CI suite green on the release branch; no quarantined tests.
## Performance status
Checkout p95 load 1.9s on throttled 3G — within the 2.5s target.
## Security status
Payment fields PCI-scoped; no new endpoints exposed. Security review signed off.
## Accessibility status
Address and payment forms pass WCAG 2.1 AA (keyboard + screen reader).
## Recommendation
Approved with known risks — two Medium defects with workarounds, fix committed for 2.4.1.
## Approver names
QA lead: A. Okafor · Product: L. Chen · Eng lead: D. Rossi
## Sign-off date
2026-06-18
EXAMPLE COMPLETED SIGN-OFF
Here's how the completed example above reads as a decision. Storefront v2.4 finished its cycle with all functional and regression testing done, 0 open Critical or High defects, and clean performance, security, and accessibility checks — so quality-wise it cleared the bar.
Two Medium defects stayed open: a missing VAT line on the confirmation email and a slow-network PayPal spinner. Both have workarounds and a committed fix in 2.4.1, and the product owner explicitly accepted the PayPal risk. That combination — bar met, only accepted risks remaining — is exactly what "Approved with known risks" means, which is why it's the recommendation rather than a clean "Approved" or a "Not approved".