Release readiness checklist: 20 checks to answer "can we ship?" with evidence

A release is ready when every high-priority requirement in it is tested and passing on the build you plan to ship, known failures are either fixed or explicitly accepted, and the team can roll back safely. The checklist below turns that into 20 checks you can run before every release, so the go/no-go conversation is about evidence, not opinions.

Why "can we ship?" is hard to answer

The question sounds simple. It usually triggers a round of messages: is QA done, did the regression pass, is that bug fixed, did anyone test the payment change? The answer lives in a spreadsheet, a test runner, a bug tracker and someone's memory. A checklist fixes the process; a live view of requirements and results fixes the chasing.

The 20-point release readiness checklist

Scope (1–4)

1. The release scope is written down: the list of stories, tickets or requirements in this release.
2. Every item in scope maps to at least one requirement ID.
3. Late additions are flagged. Anything added after the test plan was made gets explicit attention.
4. Out-of-scope changes are known. Dependency upgrades and config changes count as scope too.

Coverage (5–8)

5. Every high-priority requirement has tests. No empty rows in the traceability matrix.
6. Each requirement has negative cases, not only happy paths.
7. Numeric, date and length limits have boundary tests.
8. Changed areas have regression tests, including neighbouring features the change could affect.

Results (9–13)

9. Tests ran on the release candidate build, not on an older build.
10. The results are recent (from this build, this environment).
11. Every failure has a reason recorded: product bug, test problem or environment problem.
12. Every failing high-priority requirement is a blocker unless someone with authority accepts it in writing.
13. Flaky results are re-run and explained, not ignored.

Risk (14–17)

14. Known open bugs in scope are listed with severity.
15. Data migrations are tested on production-like data and are reversible, or have a written recovery plan.
16. Feature flags are set as intended for the rollout.
17. Monitoring and alerts cover the changed flows.

Release mechanics (18–20)

18. Rollback is tested and someone knows how to do it.
19. Release notes are written for support and customers.
20. A named person signs off go or no-go, with the evidence linked.

How to run the go/no-go meeting in 15 minutes

1. Open the live view of requirements and results, not slides.
2. Walk the blockers only: failing high-priority requirements and untested ones.
3. For each blocker decide: fix now, accept with a named owner, or pull from scope.
4. Confirm rollback and monitoring (checks 17 and 18).
5. Record the decision with a link to the evidence.

If the meeting takes longer than 15 minutes, the evidence is not in one place yet.

Release criteria: examples you can adapt

• All high-priority requirements in scope: tested and passing.
• No open critical or high-severity bugs in scope.
• Medium-priority failures: accepted in writing by the product owner.
• Regression suite ran on the release candidate within the last 24 hours.

Choose criteria your team will actually enforce. A strict rule that is always waived teaches everyone to ignore it.

Metrics that show readiness over time

Readiness for one release is a checklist. Readiness as a habit is a trend: requirement coverage, pass rate on the release candidate, escaped defects and time from code-complete to ship. We cover which ones matter in QA metrics for engineering leaders.

How testdart makes readiness visible

testdart was built so the answer to "are we ready?" is already on screen. Every requirement links to the tests that cover it; runs can be triggered when code deploys; and the report shows pass rate, the requirements affected by each failure, and a plain-English reason for why each test failed. Leaders see one live view of every requirement, test and result, and nobody has to chase a QA status update. Book a demo to see it on one of your own flows.

FAQ

Who should own release readiness? One named person per release, often the engineering manager or release manager, with QA providing the evidence.

What is the difference between release readiness and production readiness? Production readiness is about a service being operable at all (monitoring, scaling, on-call). Release readiness is about whether this specific set of changes is safe to ship.

Should a flaky test block a release? A flaky test should never be silently ignored. Re-run it, find out whether it hides a real bug, and record the decision. See why end-to-end tests are flaky.