Release readiness: six checks that tell you if a build can ship
A release readiness checklist for QA teams: scope, completion, pass rate, critical failures, open critical defects and verified requirements.
A build is ready to release when explicit, agreed checks all pass: the right test runs are in scope, enough of them are executed, the pass rate meets your bar, no critical tests are failing or blocked, open critical defects are within your limit and enough requirements are verified with none failing.
Why “is it ready?” needs a checklist
Go/no-go meetings often turn into debates because each person looks at a different number. A readiness checklist fixes that: the team agrees the checks and thresholds before testing starts, and the meeting only confirms whether the evidence meets them.
The six checks
| # | Check | Measures | A sensible starting threshold |
|---|---|---|---|
| 1 | Scope | Test runs included in the decision | At least 1 run |
| 2 | Execution completion | Run cases with a final status ÷ all run cases | 100% |
| 3 | Pass rate | Passed ÷ executed (decisive) cases | 95% |
| 4 | Critical failures | Critical-priority cases failing or blocked | 0 |
| 5 | Open critical defects | Open issues with critical priority or blocker severity | 0 |
| 6 | Requirements verified | Requirements whose tests all pass | 80%, and none failing |
The build is ready only when all six pass.
Check 1: scope
Decide which runs count: the regression run for this release candidate, the smoke run on staging, the automated suite from CI. A decision based on zero runs is not a decision, so the minimum is one.
Check 2: execution completion
Untested cases are unknown risk. Completion is the share of cases in scope with a final result. Do not let skipped or untested cases improve the pass rate; they belong here.
Check 3: pass rate
Pass rate on its own hides a lot. 96% sounds healthy until you notice the 4% are payment tests. That is why it is paired with the next check.
Check 4: no critical test failing or blocked
A single failing critical case should stop a release regardless of the overall pass rate. Blocked counts too: a critical case nobody could execute is not verified.
Check 5: open critical defects
Count open issues with critical priority or blocker severity. Many teams allow zero; some allow a small number with documented workarounds.
Check 6: requirements verified
Pass rate is about tests; customers care about requirements. Require a minimum share of requirements passing, and no requirement failing. See the requirements traceability matrix guide for how requirement status is derived.
Make every number explainable
Each check should show the counts behind it, for example “47 of 81 cases have a final status” rather than just “58%”. When a check fails, link straight to the cases and defects responsible. Numbers people can trace are numbers people trust.
When the answer is “not ready”
- Run the riskiest cases first. Use risk-based testing to pick what to execute in the time left.
- Retest failures once fixes land, in a follow-up run of only failed and blocked cases.
- Check for flakiness before blaming the build; a flaky test should not block a release on its own.
- Re-check and record the final verdict with the report for sign-off.
Automate the checklist
TestPlum computes all six checks from recorded results with thresholds you set, shows the numbers behind each one, and prints the verdict for sign-off. See reports and release readiness.
Frequently asked questions
What pass rate is good enough to release?
There is no universal number; it depends on risk. Many teams start with 95% overall plus a hard rule that no critical-priority test may be failing or blocked, and tighten the bar for regulated or high-traffic releases.
Who decides if a release is ready?
The decision usually belongs to a release owner or QA lead, but the criteria should be agreed in advance by product, engineering and QA so the go/no-go meeting checks evidence rather than debating opinions.
Should skipped tests count toward release readiness?
Skipped and untested cases should lower execution completion, not raise the pass rate. Calculate pass rate from decisive results only, and track completion separately.