Release readiness is a risk decision informed by multiple pieces of evidence. QA can help make that evidence visible and explicit.
Coverage
What changed, what was tested, what was not tested, and whether the validation covered the highest-risk areas affected by the release.
Defects
Open defects should be understood by severity, user impact, workaround, affected scope, and release acceptance — not just counted.
Dependencies
External services, configuration, migrations, feature flags, integrations, and environment differences can introduce risk that ordinary regression does not expose.
Operational evidence
Logs, monitoring, deployment checks, rollback readiness, and production validation can matter as much as pre-release functional testing.
Known limitations
A release can still be reasonable with known gaps when those gaps are explicit, accepted by the right stakeholders, and supported by a mitigation plan.
The goal
The purpose of release readiness is not to make QA the gatekeeper. It is to give the delivery team a clear picture of remaining risk before the decision is made.