Delivery
Quality as a Release Gate, Not a Phase
- May 20, 2026
- 5 min read
- 4 sections
Teams still talk about “QA phase” as if quality is a station the build visits once. In practice, defects that reach that station are already expensive. We treat quality as a sequence of gates: each one must pass before the work can move closer to production.
01Define done before work starts
Acceptance criteria, edge cases, and non-functional expectations belong in the ticket — not in a Slack thread after merge. When “done” is fuzzy, every gate becomes a negotiation.
02Automate the boring checks
Lint, typecheck, unit coverage on critical paths, and smoke tests on the happy path should run on every pull request. Humans should spend attention on judgment calls, not on catching typos the pipeline already knows how to find.
03Keep a human gate for risk
Exploratory testing, permission matrices, and migration rehearsals still need people. Gate them by risk: money movement, auth, data deletion, and irreversible ops get explicit review before release.
04Close the loop after ship
A release gate without post-deploy checks is incomplete. Smoke the critical flows in production, watch error budgets, and feed what broke back into the next ticket’s definition of done.