Release Gates & Go/No-Go Decisions
A release gate is a formal checkpoint. The test summary report is QA’s contribution to the Go/No-Go decision. The quality of that report determines whether the organisation makes a good decision or a dangerous one.
1 The Hook
A NZ SaaS company has a Friday afternoon release scheduled. The test lead says “98% pass rate, recommend go.” The CEO says go. Saturday morning: a payment processing bug affects 2,400 transactions.
Post-incident review: the 2% failure rate included 14 payment-related test failures. The dev team had categorised them as “low priority.” The test summary reported 98% pass — technically accurate. It did not say “the 2% failure includes the payment flow.”
The report was correct. It was not decision-ready. The CEO made a dangerous decision because the report gave him a number, not a risk picture.
That is the problem a proper Go/No-Go test summary solves.
2 The Rule
A Go/No-Go recommendation is a risk statement, not a pass/fail count. The decision-maker needs to understand what was tested, what failed, what risk is being accepted, and what the consequence of that risk is.
3 The Analogy
A pre-flight checklist review by the co-pilot.
“All systems green” is not enough. “Engine 2 is showing a caution light — it’s within operational parameters but worth watching” is what a responsible co-pilot says. Air traffic control clears the flight because they have the full picture.
A test summary that says “98% pass rate” without explaining what the 2% means is like a co-pilot who says “all green” when engine 2 is in caution. Accurate. Dangerous.
4 Watch Me Do It
Here is a one-page Go/No-Go test summary that gives decision-makers what they need. This is the format. Adapt it to your programme.
Three things make this report decision-ready:
- Scope is explicit. The decision-maker knows what was and was not tested. The 6 skipped tests are named, not hidden in the pass rate denominator.
- Failures are contextualised. Not just a count — severity, status, and the consequence of each outstanding defect.
- The recommendation names the reason. Not “12 failures” but “CRITICAL defect in reconciliation engine, risk of data corruption.” That is a sentence the CTO can act on.
5 When to Use It
Before every production release. No exceptions. The format scales — a two-person team releasing a patch still needs a Go/No-Go decision, even if it is a one-paragraph Slack message with a pass/fail and a risk statement.
Entry criteria (what must be complete before testing starts) and exit criteria (what must be true before releasing) must be defined at the start of each sprint or release cycle. You cannot measure quality against criteria that do not exist.
6 Common Mistakes
🚫 “I used to think: 95%+ pass rate always means go.”
Actually: 1 critical payment failure in 1,000 tests is a NO-GO. Pass rate percentage is meaningless without context of what failed. A 99% pass rate with 1 critical security defect outstanding is still a NO-GO. Always name what failed and why it matters.
🚫 “I used to think: the test lead makes the Go/No-Go decision.”
Actually: The test lead makes the recommendation. The risk owner — CTO, product owner, or release manager — makes the decision. Never conflate the two. The test lead who says “I decided to go-live” has taken on liability that is not theirs to carry.
🚫 “I used to think: deferred defects don’t need to be mentioned in the test summary.”
Actually: Every known defect accepted into production must be documented in the release notes and the test summary. Undocumented known issues create liability. If something breaks in production and you knew about it and said nothing, that is a governance failure — not just a quality one.
7 Now You Try
Write a one-page Go/No-Go test summary for an NZ bank’s new internet banking login feature. Test results: 312 tests run, 298 pass, 8 fail (2 critical: session management; 4 medium: UI glitches; 2 low: help text errors), 6 skipped due to environment issues. The critical failures affect token rotation. Make a recommendation and justify it.
8 Self-Check
Click each question to reveal the answer.
Q1: Why is a 98% pass rate insufficient information for a Go/No-Go decision?
Because pass rate percentage says nothing about what the 2% failure contains. One critical defect in a payment flow, a security bypass, or a data corruption risk can make the 2% a NO-GO regardless of the overall percentage. The decision-maker needs to know what failed and what the consequence is.
Q2: Who makes the Go/No-Go decision?
The risk owner — CTO, product owner, or release manager. The test lead makes the recommendation and provides the evidence. The decision and its consequences belong to the risk owner, not to QA.
Q3: What must happen to deferred defects?
Every known defect accepted into production must be documented in the test summary and the release notes. Undocumented known issues create legal and governance liability. If a known defect causes a production incident and it was not documented, the organisation cannot demonstrate it made an informed decision.
Q4: When should entry and exit criteria be defined?
At the start of each sprint or release cycle, before testing begins. Criteria defined after testing is complete are invented to match results, not to measure quality. Pre-agreed criteria give the test lead an objective measure to report against under pressure.
Q5: What are the three elements that make a test summary decision-ready?
Explicit scope (what was and was not tested), contextualised failures (severity, status, and consequence of each outstanding defect), and a recommendation with a named reason — not a number, but a sentence the decision-maker can act on.
9 ISTQB Mapping
The ISTQB Test Manager syllabus covers test progress monitoring, test reporting, and the test completion report. Key concepts: exit criteria evaluation, defect metrics in context of risk, and the distinction between the test manager’s role (provide evidence and recommendation) and the stakeholder’s role (make the decision). This lesson translates those concepts into a practical NZ-context Go/No-Go report format.
10 Next Steps
You can make a sound Go/No-Go decision when your environments are clean and your data is representative. Next: how to manage test data across environments without breaching the NZ Privacy Act 2020.