Quality Gates
A quality gate is a checkpoint between two stages of delivery where the evidence about a change or a release is compared with criteria agreed in advance, and the result decides whether the work may move on. For example, before a pull request can be merged, the build must succeed, all unit and API tests must pass, and the dependency scan, which checks the third-party libraries the code uses for known security vulnerabilities, must report no new critical ones. If any check fails, the merge stays blocked until the problem is fixed.
In the lesson on entry and exit criteria you defined when an activity may start and when it is done. A gate is where such criteria are checked and enforced: the exit criteria of one stage often double as the entry criteria of the next, and the gate sits between them. Some gates are automated pipeline checks; others are a decision by a named person in the release process. The ISTQB glossary describes a quality gate as a milestone between project phases that depend strongly on the outcome of the previous phase, with a formal check of what that phase produced. Teams also say stage gate or checkpoint, and a gate just before production is often called a release gate.
Why it matters
Without a gate, "ready" is decided by whoever is under the most pressure that day. A failing test ignored at merge breaks the main branch for the whole team; a known critical defect that slips through becomes an incident for users. A gate replaces that argument with a check against rules agreed calmly in advance, and it stops known problems while they are still cheap to fix.
For a tester, gates are where quality information decides something: test results, coverage and defect counts matter only when they feed a decision. A gate also makes the decision visible. If a release ships although a criterion was not met, the record shows who accepted the risk and why, instead of the problem later turning into "QA missed it".
Where gates sit: the pipeline and the release process
Every gate has the same parts: a position between two stages, pass/fail criteria, the evidence each criterion is read from (a pipeline report, a test report, the defect tracker), an owner and an action on failure. What differs is who decides.
Pipeline gates are automated and run on every change; platforms such as GitHub and GitLab can make a pipeline result a required check, so a pull request cannot be merged while it is red. Release-process gates are fewer: a person reviews the evidence for a whole release and decides. Most teams combine both:
- Merge gate (automated): build, static checks, unit and API tests on every pull request; a red check blocks the merge.
- Test exit gate: after system and regression testing, the exit criteria from the test plan are checked against the test report.
- Release gate (a person decides): before production, the gate owner reviews the evidence and decides go or no-go, or approves a recorded exception.
- Post-deploy gate: smoke tests and health checks run right after the deployment; a failure triggers a rollback.
- 1Pull requestBuild, static checks, unit and API tests on every changeAutomated
Branch: Any check red → merge blockedFail
Gate: Merge gate: all required checks green
- 2Test environmentSystem and regression testing of the merged build
Branch: Exit criteria not met → keep testing or fixFail
Gate: Test exit gate: exit criteria met in the test report
- 3Release candidate on stagingThe gate owner reviews the evidence for the whole releaseA person decides
Branch: No-go → fix, re-test, new candidateFail
Gate: Release gate: go, or a recorded exception
- 4Production: post-deploy gateSmoke tests and health checks right after the deployAutomated
Branch: A check fails → roll backFail
Then:All checks pass: the release stays live
- Exception (waiver)Approved only by the gate owner or a named deputy; records the criterion not met, reason, risk, mitigation and expiry
Illustrative: the number and position of gates differ from team to team.
Gate criteria that work
A useful criterion is measurable, tied to a real risk, quick enough to evaluate at its stage and agreed before the work starts. "Quality is acceptable" fails the first test, because nobody can say whether it was met; "no open blocker or critical defects" can meet all four. The policy below is illustrative, not the syntax of any CI tool, and its numbers are examples: take yours from your own baseline.
Avoid vanity criteria. "Line coverage at least 80%" and "95% of tests pass" can both be met while checkout is broken: the first rewards tests that check nothing, the second hides which 5% failed. Coverage shows what is untested; it does not prove quality. Prefer "every acceptance criterion in scope has a passing test" and "no failing test in the critical-journey suite".
gates:
- name: merge
owner: engineering-lead
on_failure: block
criteria:
build: passed
failed_unit_and_api_tests: 0
skipped_tests_without_ticket: 0
breaking_api_contract_changes: 0
new_critical_or_high_vulnerabilities: 0
- name: release-to-production
owner: product-owner
on_failure: no-go-unless-approved-exception
criteria:
failed_regression_tests: 0
acceptance_criteria_without_passing_test: 0
open_blocker_or_critical_defects: 0
checkout_api_p95_ms_max: 800
- name: post-deploy
owner: release-engineer-on-call
on_failure: roll-back
criteria:
failed_smoke_tests: 0
failing_health_checks: 0Try it: YAML Formatter Try it: Requirements → Test Cases Try it: Response Contract Comparator
Who owns a gate, and how exceptions are handled
Every gate needs a named owner who maintains its criteria and decides on exceptions: usually the engineering lead for the merge gate, the security function for security criteria, and the product owner or a release manager for the release gate. The tester rarely owns a gate alone; the tester provides the evidence and a clear recommendation, and the owner decides and is accountable.
Exceptions will happen, for example when an urgent fix must ship while an unrelated check is red, and a gate without an exception process gets bypassed informally. The ISTQB Foundation syllabus says something similar about exit criteria: when time or budget runs out, ending testing without meeting all of them can be acceptable if the stakeholders have reviewed and accepted the risk. So make exceptions explicit:
- Only the gate owner or a named deputy approves, never the person asking for the exception.
- The record states the criterion not met, the reason, the risk in user terms, the mitigation and the approver.
- Every exception has an expiry and a follow-up ticket with an owner.
- A flaky test is quarantined with a ticket: moved out of the blocking suite into a separate run that is still watched, never deleted or silently skipped.
- A criterion that is waived again and again is either wrong or ignored; change it openly.
Worked example: a release that fails one criterion
An online store plans release 3.4 with a new discount-code feature. Its release gate, owned by the product owner, has four criteria: the regression suite passed; every acceptance criterion in scope has a passing test; no open blocker or critical defects; checkout API p95 latency at most 800 ms at smoke load. The QA lead provides the evidence.
On release day 412 of 412 regression tests pass, all 38 acceptance criteria have passing tests and p95 latency is 640 ms. But one critical defect is open: DEF-1182, the discount is applied twice when the user double-clicks "Apply" on a slow connection. The gate fails: either the release waits for a confirmed fix, or the owner approves an exception.
The rest of release 3.4, including fixes customers are waiting for, is ready, and the new feature is behind a feature flag, so the team proposes to release with the flag off. The product owner approves, and the exception is recorded:
- Gate and criterion not met: the release gate for 3.4; "no open blocker or critical defects" (DEF-1182 is open).
- Reason and risk: the other changes in 3.4 are needed on the planned date; if the flag were switched on, customers could get the discount twice.
- Mitigation: the flag stays off in production; the QA lead verified on staging that the discount field is then unreachable and checkout behaves as in release 3.3.
- Approved by: the product owner, after review with the QA lead and the engineering lead.
- Expiry and follow-up: DEF-1182 is the follow-up ticket, owned by the engineering lead; the flag stays off until its fix passes confirmation testing and regression testing, and the exception closes with release 3.5 at the latest.
Common mistakes
- Criteria that cannot be measured, such as "quality is good enough" or "most tests pass".
- Raw vanity thresholds, such as 80% line coverage, that can be met while critical journeys are broken.
- Skipping or deleting a failing test to turn the gate green, instead of quarantining it with a ticket.
- Verbal exceptions with no record, no approver and no expiry, which nobody follows up.
- A merge gate made so slow by long suites that people start working around it; long suites belong in later gates or scheduled runs.
- Treating the tester as the only gatekeeper: the tester supplies evidence and a recommendation, the named owner decides.
The QA perspective
Get involved when the gates are designed, usually during test planning. Propose criteria tied to the product risks you identified, check that each has a data source (the pipeline report, the test management tool, the defect tracker), and ask who owns each gate and who may approve an exception, for how long. Write the answers into the test plan or the team's working agreement.
At a gate, your job is evidence: each criterion, its actual value, pass or fail, and where the report is. When a criterion is not met, describe the risk in user terms, give your recommendation and let the owner decide; if the risk is accepted, make sure the exception is recorded and its follow-up ticket assigned. Review exceptions at the retrospective: a gate that is always waived has stopped being a gate.
Practice exercise
Design the gates for a small product team
A team of six builds a food-ordering web app, merges about fifteen pull requests a day and releases every two weeks. Last month a pull request was merged with a failing unit test because "that test is flaky anyway"; a release shipped with a known critical defect in refunds, and nobody knows who decided that; and after one deployment the order-tracking page returned HTTP 500 for 40 minutes until a customer reported it.
Propose gates that would have stopped each problem, and an exception rule the team can work with.
- For each incident, name the gate that should have caught it and where it sits.
- Write two or three measurable criteria per gate and the evidence each is read from.
- Name each gate's owner and the action on failure.
- Write the exception rule: who approves, what is recorded, when it expires.
Show the model answer
Merge gate, which stops the first incident (automated, every pull request; owner: engineering lead): build passed, zero failed unit and API tests, no test skipped without a ticket; evidence: the pipeline report. On failure the merge is blocked; a flaky test is quarantined with a ticket, not ignored.
Release gate, which stops the second (before production; owner: product owner; evidence from the QA lead): regression suite passed, every acceptance criterion in scope has a passing test, no open blocker or critical defects; evidence: the test report and the defect tracker. On failure: no-go unless an exception is approved, so the refund defect is fixed or knowingly accepted by a named person.
Post-deploy gate, which stops the third (after every deployment; owner: the release engineer on call): smoke tests of the critical journeys, including order tracking, and health checks of the main APIs pass on production; evidence: the deployment pipeline report. On failure, roll back, so the team finds the broken page instead of a customer.
Exception rule: only the gate owner or a named deputy approves; the record holds the criterion not met, reason, risk, mitigation and approver; each exception has a follow-up ticket, expires at the next release at the latest and is reviewed at the retrospective.
Frequently asked questions
Is a quality gate the same as exit criteria?
Not quite. Exit criteria are the conditions that say an activity is done. A quality gate is the point in the process where conditions like these are checked and the decision is enforced. A gate between two stages usually checks the exit criteria of the first, which often double as the entry criteria of the second.
Should the tester be the one who stops a release?
The tester provides the evidence and a recommendation, and says clearly when a criterion is not met. The decision belongs to the gate owner, often the product owner or a release manager, because they own the business risk. If the evidence is misrepresented or a gate is bypassed without a record, the tester should escalate.
Can a gate be too strict?
Yes. A gate that is slow, noisy because of flaky tests or built on vanity numbers teaches people to work around it. Keep fast checks in the merge gate and slower suites in later gates or scheduled runs, track how often the gate blocks wrongly or is waived, and change the criteria openly when they prove wrong.
References
- ISTQB Certified Tester Foundation Level (CTFL) v4.0The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
- ISTQB GlossaryThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.
- Continuous Integration (Martin Fowler)The widely referenced description of continuous integration: integrate often, keep the build self-testing and fast, and fix a broken build immediately.
- Eradicating Non-Determinism in Tests (Martin Fowler)Why flaky tests destroy a suite's value, their common causes (isolation, asynchrony, remote services, time, resource leaks) and quarantine as a response.
Practise with Mutqan tools
Check several API health endpoints at once and get status, latency and a pass/fail summary.
Convert a list of numbered requirements into traceable test cases with a requirement-to-test matrix.
Compare an actual API response against an expected contract (example or schema) and report breaking vs non-breaking differences.
Measure an endpoint's response time over several samples: min, max, average, median and p95.
Format and validate YAML with consistent indentation and quoting.
Score features by likelihood and impact, then generate a prioritised risk-based test plan.
Go deeper
Your progress on this topic
Not started
Mark the topic complete when you have studied it and done the exercise.
Sign in to track your progress
Mark topics complete, continue where you left off and unlock specialisation exams.