Release Readiness and Go/No-Go

Why it matters

Releases fail for reasons no test case checks: a data migration that cannot be undone, an alert nobody configured, a support desk that learns about a changed screen from angry customers. A readiness review asks about these before users find them, and turns "are we ready?" from a mood into a decision with criteria, evidence and an owner.

For a tester, this is where the work is used. The ISTQB Foundation syllabus lists giving stakeholders information for informed decisions among the objectives of testing. A tester who presents evidence and residual risk clearly, instead of a vague "QA approves", earns trust, and the recorded decision shows who accepted which risk.

Readiness is more than test results

A readiness checklist groups criteria into areas, each with a lead who answers for it. Names vary, and some organisations hold a separate operational readiness review, but most checklists cover four areas, and every criterion names the evidence it is read from:

• Product: test exit criteria met; no open blocker or critical defects; known issues have a workaround; non-functional targets met. Evidence: the test report and the defect tracker.
• Operations: deployment and rollback steps written and rehearsed; data migrations reversible or covered by a recovery plan; monitoring and alerts cover the new parts; someone is on call. Evidence: the rehearsal record and the dashboards.
• Support: the team is briefed, has a known-issues note with workarounds and knows where to escalate. Evidence: the published note.
• Business: release notes and user messages approved; legal or contractual approvals in place; partners and providers ready. Evidence: the approvals.

Try it: API Health Checker

From quality gates to the go/no-go meeting

Recall from the lesson on quality gates: a gate checks agreed criteria at a fixed point, and a release gate is owned by a person who decides. The go/no-go meeting reads the results of the earlier gates instead of repeating them; what it adds is evidence the pipeline cannot produce, from operations, support and the business, and a judgement about the risk that remains.

Mark each criterion must-have or should-have when the checklist is written, not in the meeting. A must-have that is not met means no-go, unless the decision owner explicitly accepts a conditional go; an unmet should-have is reported as a risk the owner may accept.

Hold the meeting a day or two before the release, with a short final check just before deployment for anything still open. The decision owner, often the product owner or a release manager, chairs and decides; the QA, engineering, operations and support leads attend. Everyone gets the checklist, the test completion report and the residual-risk statement beforehand: a surprise in the meeting means the reporting failed.

Go/no-go meeting, release 2.8 (30 minutes)
Decision owner: product owner
Inputs sent 24 hours before: checklist, test completion report,
                             residual-risk statement, open defects

1. Scope: what is in, what was pulled out since the plan
2. Criteria: status and evidence link for each, must-haves first
3. Open defects and risks: impact on users, workaround, mitigation
4. Area leads (product, operations, support, business): ready or not
5. Decision: go, conditional go or no-go, stated by the owner
6. Record and send: decision, conditions, owners, deadlines, fallbacks

Try it: Markdown Formatter Try it: Risk-Based Test Generator

Go, no-go and conditional go

Go means every must-have is met and the decision owner accepts the known residual risks. No-go means a must-have is not met and cannot be contained in time; it is a decision, not a failure, and it states what must change and when the team decides again.

Conditional go means the release proceeds only if named conditions are met. A condition can apply before deployment; during the rollout, when the release first reaches one region or a canary and widens only while agreed signals stay healthy (Google's Site Reliability Workbook describes canarying as a partial, time-limited deployment of a change and its evaluation); or after the release, such as a known issue fixed by a date. "Go, and we will fix it later" is not a condition. A real condition has five parts:

• A checkable result: "rollback rehearsal passes on staging", not "rollback looks fine".
• An owner who reports when it is met.
• A deadline or trigger: before deployment, a rollout step or a date.
• A fallback if it is not met: no-go, stop the rollout, roll back or switch a feature flag off.
• The decision owner's recorded acceptance of the risk while the condition is open.

Try it: Decision Table Generator

Worked example: the go/no-go for release 2.8

A clinic-booking web app plans release 2.8 for Thursday 22:00: online deposits for bookings (new, behind a feature flag that can be switched on per clinic) and 14 fixes. At the go/no-go meeting on Wednesday the QA lead reports 286 of 286 regression tests passed, a passing test for every acceptance criterion in scope and no open blocker or critical defects. One major defect is open: DEF-417, the receipt email omits the clinic address for bookings made in Arabic.

Two gaps remain: the rollback of the database change that adds the payments table, a must-have, has not been rehearsed, and the support briefing is planned for Thursday 09:00. The QA lead adds a residual risk: payments were tested against the provider's test environment, and the production account was activated only yesterday. The product owner decides: conditional go.

• C1, before deployment: the rollback rehearsal passes on staging by Thursday 16:00. Owner: engineering lead. Otherwise: no-go, next window Sunday.
• C2, before deployment: support is briefed and a known-issue note for DEF-417 is published. Owner: support lead. Otherwise: deposits stay switched off.
• C3, during the rollout: deposits are switched on for one clinic and the QA lead makes one small real payment and refund in production; the other clinics follow the next morning only if the provider shows no failed or duplicate charges overnight. Owner: QA lead with the on-call engineer. Otherwise: flag off, and bookings continue without deposits.
• C4, after release: DEF-417 is fixed in 2.8.1 within seven days. Owner: engineering lead. Otherwise: the product owner reviews the accepted risk again, and the known-issue note stays published until the fix ships. Accepted risk: some Arabic receipt emails lack the address.
• Final check, Thursday 17:00: C1 and C2 are met with evidence links, the product owner confirms go, and the decision record goes to all stakeholders.

Try it: Markdown to PDF

Frequently asked questions

References

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• Canarying Releases — The Site Reliability WorkbookGoogle / O'Reilly MediaReleasing a change to a small share of traffic first and comparing it with the baseline before rolling out — deployment verification as practised in SRE.
• DORA's software delivery performance metricsDORA (Google Cloud)The DORA delivery metrics — change lead time, deployment frequency, failed deployment recovery time, change fail rate and related measures — grouped by throughput and instability.