QA glossary
What is release readiness?
Release readiness is the judgement of whether a software release is safe to ship, based on evidence such as test results, open defects, unresolved blockers and how much of the change was tested. It is a go or no-go decision made against criteria agreed in advance, not a feeling on release day.
An example from QA practice
A team agrees its exit criteria at the start of the sprint: no open critical or high-severity defects, at least 95% of planned tests passed, every payment flow regression tested and a rollback plan written. On Thursday evening 96% of tests pass, but a high-severity defect in partial refunds is still open. The answer for that build is no-go. The defect is fixed, the refund area and the regression suite are re-run, and the release moves to Monday.
What goes into the decision
The evidence is usually a short list, and each item needs a number or a name behind it:
- Test results: pass rate for the planned tests, and which ones did not run.
- Open defects: counted by severity, with every blocker named.
- Coverage of the change: whether the areas that changed were actually tested.
- Accepted risks: known issues someone with authority chose to ship with, in writing.
- Rollback: how the release is undone if it goes wrong.
Who decides
QA reports the evidence and the product owner or release manager makes the call. Shipping with a known defect is a legitimate decision when the owner accepts the risk and records it. What goes wrong is a release that ships on the date because nobody was asked. A tester outside the delivery team has no stake in the date, which is why independent testing gives a cleaner readiness view.
How BetterQA does it
BugBoard has a release readiness check that looks at pass rates, open bugs, blockers and coverage, and returns a go or no-go recommendation. It is a recommendation: the decision stays with your release owner, and our engineers explain what sits behind it.