QA Process
QA Process for Agile.
In agile, QA isn't a phase at the end — it runs through the whole sprint, from refinement to release. This guide shows where testing fits, how shift-left works in practice, and how to keep QA from becoming the bottleneck.
When to use it
Use this when adapting QA to a sprint cadence, when testing keeps getting squeezed into the last two days, or when QA has become the thing every release waits on.
Who uses it
Senior QA and leads embedding testing into an agile team, QA engineers working sprint to sprint, and the scrum masters and product owners who shape how quality fits the process.
On this page9 sections
WHAT AGILE QA LOOKS LIKE
Agile QA replaces the old "build it, then test it" handoff with testing woven through every stage of the sprint. QA is involved from refinement onward — shaping testable stories, testing as features are built, and feeding results back continuously rather than in one big phase at the end.
The mindset shift is from gatekeeper to participant. Instead of QA being a checkpoint work passes through, quality becomes a shared, ongoing activity the whole team owns, with QA providing the testing expertise that keeps it honest. Done right, testing stops being the thing that happens after development and becomes part of how development happens.
WHERE TESTING FITS IN A SPRINT
Testing has a role at every stage of the sprint, not just at the end. Mapping it stage by stage is the clearest way to see that QA work is continuous.
Refinement → dev → test → release
Refinement — QA reviews stories for testability, sharpens acceptance criteria, and raises edge cases before the work is committed.
Development — QA designs test cases and prepares data in parallel while developers build, so testing is ready the moment code is.
Test — QA verifies each story as it's completed, not in a batch at the end; defects are raised and fixed within the sprint.
Release — QA confirms the increment meets its Definition of Done and the release readiness bar, feeding the go / no-go.
SHIFT-LEFT IN PRACTICE
Shift-left means moving testing activities earlier — toward where the code is written rather than a stage at the end. In practice that's QA in refinement catching ambiguous requirements, developers writing unit and integration tests, and automated checks running on every pull request so defects are caught in minutes, not days.
The payoff is cost: a defect found in refinement is a conversation, the same defect found in production is an incident. Shifting left doesn't remove later testing — it means far less of it is firefighting, because most problems were caught while they were still cheap to fix.
QA IN AGILE CEREMONIES
QA has a distinct contribution in each agile ceremony, and showing up with that contribution is how testing stays embedded rather than bolted on.
Standup, planning, review, retro
Standup — QA surfaces testing progress and blockers daily, so a stuck test is known on day two, not day nine.
Planning — QA inputs test effort and risk into estimates, so the sprint commits to what can actually be tested, not just built.
Review — QA helps demo working, tested increments and flags anything not yet meeting the Definition of Done.
Retro — QA raises testing pain points (flaky environments, late handoffs) and turns them into owned process actions.
DEFINITION OF READY & DONE
Two shared gates keep quality from leaking at the edges of the sprint. A Definition of Ready stops untestable stories entering — testable acceptance criteria, known dependencies, available data. A Definition of Done stops under-tested ones leaving — criteria verified, no open Critical/High defects, automation green.
In agile these gates matter even more than in a phased process, because there's no big test phase at the end to catch what slipped. The gates are the safety net; the dedicated guide on building them (linked below) goes deeper into the checklists.
CONTINUOUS TESTING & CI
Continuous testing means automated tests run constantly through the pipeline — on every commit, every pull request, every merge — so the team gets fast, ongoing feedback instead of a manual test pass at the end. It's what makes a true sprint cadence possible: you can't ship every two weeks if regression takes a week to run by hand.
Wiring testing into CI/CD is the enabler. Unit and integration tests gate merges, a smoke suite confirms each deploy is stable, and the regression pack runs automatically — so humans spend their time on exploratory and risk-based testing where judgement matters, not on re-running the same checks every release.
AVOIDING THE QA BOTTLENECK
The classic agile QA failure is the mini-waterfall: developers build all sprint, then dump everything on QA in the last two days, and testing becomes the bottleneck every release waits on. The fix isn't more testers — it's removing the batch. Test stories as they're completed through the sprint, not all at once at the end.
Several practices keep QA flowing: developers testing their own work before handoff, automation absorbing the repetitive regression load, QA pairing with devs early, and stories sized small enough to build and test within the sprint. When quality is the whole team's job rather than a final gate, the bottleneck disappears because the work was never piled up behind one.
COMMON MISTAKES
Running a mini-waterfall inside the sprint.
Don't batch all testing into the last two days. Test each story as it's completed so QA never becomes the end-of-sprint bottleneck.
Bringing QA in only after development.
Involve QA from refinement — shaping testable stories and catching ambiguity early is cheaper than finding it in test.
Treating quality as QA's job alone.
Developers test their own work and write automated checks; the whole team owns quality. QA can't inspect it in at the end.
Skipping automation and CI.
A sprint cadence needs continuous, automated feedback. Manual-only regression can't keep up with shipping every two weeks.
Committing to more than can be tested.
Factor test effort into planning. A sprint that's only sized for development guarantees testing gets squeezed.