Cross-posted from the Unitix Flow Blog
QA doesn't belong at the end of your release cycle. It belongs inside it.
Most teams treat testing as the last step before deployment: code freeze → hand to QA → wait for sign-off → deploy. This "QA phase" approach has predictable failure modes.
Why End-of-Cycle QA Breaks
Scope instability. Features keep getting added until the last minute. The test plan written on Monday is invalid by Wednesday because two tasks were added and one was removed.
Schedule compression. Development runs late, but the release deadline doesn't move. The testing window shrinks from 3 days to 1. QA rushes, skips edge cases, and signs off with lower confidence.
Expensive bugs. Bugs found at the end of the cycle are the most expensive. Code is already integrated, merged to staging, and possibly deployed to a shared environment. Fixing means re-testing everything.
QA as bottleneck. When testing is the last step, QA becomes the perceived blocker. "We're waiting on QA" becomes the default excuse, even when the delay started in development.
The Alternative: Embedded QA
Instead of a phase at the end, QA becomes a continuous activity throughout the release.
Test Planning Starts During Development
When a feature is planned, its test cases are planned alongside it. The developer who builds the feature also defines what needs to be tested. QA reviews, expands, and adjusts — but the foundation exists before code is written.
Developer Self-QA (Gate 1)
Before merging to staging, the developer tests their own feature against the defined test cases. This catches obvious issues early and respects QA's time — they shouldn't find typos and broken buttons.
Staging QA (Gate 2)
Once features are merged to the staging branch, QA runs the full test suite: smoke tests + relevant regression tests. This is where integration bugs surface — feature A works, feature B works, but A + B together breaks.
Scope Lock
When QA testing begins, the release scope is frozen. No new features. No "just one more small PR." New work goes to the next release. This gives QA a stable target.
Pre-Deploy Sanity (Gate 3)
5-7 critical tests run right before production deployment. Not a full re-test — just a final confidence check that the most important flows work.
The Impact
When QA is embedded throughout:
- Bugs are found earlier, when they're cheap to fix (before integration, not after)
- QA engineers are partners, not gatekeepers. They're involved from planning to deploy.
- Testing time per release decreases — counterintuitive, but testing a stable scope with pre-planned cases is faster than ad-hoc testing of a moving target
- "Did anyone test this?" disappears — every feature has documented test cases with explicit pass/fail status
Making It Practical
The shift doesn't require new tools (though they help). It requires:
- Invite QA to sprint planning
- Require test cases alongside feature specs
- Define explicit QA gates between stages
- Lock scope when testing starts — no exceptions
- Track test results per release, not just per sprint
Unitix Flow builds QA gates into the release lifecycle — test cases linked to releases, staging branch testing, scope lock, and persistent test history across releases.
Top comments (0)