In waterfall, QA had a clear role: test the build after development was done. In agile, the role is less defined and more contested. Some teams embed QA engineers in every squad, others expect developers to do all testing, and a few run a shared QA pool that floats between teams. None of these models is universally right, but the choice matters.
This guide covers how QA in agile actually works across scrum frameworks. We’ll map the QA role to each sprint ceremony, compare three workflow models, and walk through the story-to-done lifecycle that keeps quality from slipping.
The QA Role in Agile Has Changed
The classic “gatekeeper at the end of the pipeline” model doesn’t fit a two-week sprint. Agile QA engineers work alongside developers from the first refinement meeting, not after code is merged. The role shifted from finding bugs to preventing them.
That shift pushed QA into two partly overlapping responsibilities. One is testing: writing automation, running exploratory sessions, verifying acceptance criteria. The other is coaching: helping developers write testable stories, pairing on unit tests, and driving quality conversations in retros. A strong agile QA engineer does both, though the mix depends on team maturity.
The debate over dedicated QA versus “whole team” quality still runs hot. Lisa Crispin and Janet Gregory, whose work on agile testing shaped the modern playbook, have long argued that quality is a team responsibility regardless of whether a dedicated QA seat exists. The Agile Alliance’s QA practices overview echoes the same theme: quality belongs to everyone, but someone usually has to own the practice.
When does each model work? Dedicated QA engineers pay off on high-risk products, regulated industries, and any team shipping to enterprise customers. Whole-team quality works for small teams with strong engineering culture and automated test coverage above roughly 70%. Most teams land somewhere in between, which is where the ceremonies matter most.
QA in Sprint Ceremonies
Sprint ceremonies are where QA responsibilities in scrum get defined in practice. Each ritual has a different purpose, and QA’s contribution changes with it. If you’re building a QA process from scratch, mapping QA activities to each ceremony is the fastest way to make the role legible to the rest of the team.
Sprint Planning
QA reviews every candidate story for testability before the team commits to it. A story without clear acceptance criteria, observable outputs, or a reproducible setup is a story that will stall in QA at the end of the sprint. Flagging these in planning saves days later.
QA also adds testing effort to story points. If a story needs a new automation suite, a data seed, or a third-party sandbox, that’s additional work and it belongs in the estimate. The Scrum Guide (2020) is explicit that the sprint goal and backlog are a whole-team commitment, which means testing estimates belong in the same conversation as development estimates.
Daily Standup
The QA update in standup isn’t “I tested things yesterday.” It’s three things: what’s blocked, what’s ready for dev attention, and what’s at risk of not making it into the sprint. Good QA engineers surface risk in the first sentence, not the last.
Standup is also where QA coordinates with developers on feature readiness. If a story moves to “in QA” and the build doesn’t deploy cleanly, that’s a five-second conversation in standup rather than a 30-minute DM chain later. The goal is to close the loop quickly.
Sprint Review and Demo
During the demo, QA validates that each demoed feature passes the acceptance criteria the team committed to. That validation should be short and factual: “tested on Chrome and Safari, acceptance criteria met, two minor UI bugs filed.”
QA also brings a testing summary. Pass/fail counts, bugs found, regression status, and automation coverage deltas for the sprint. Stakeholders don’t need a spreadsheet, but they do need a signal that quality is tracked, not assumed.
Sprint Retrospective
The retro is the best place to turn quality into a metric the team actually looks at. Bugs that escaped to production, flaky tests that wasted cycles, regressions that reappeared, and coverage changes are all useful data. Bring two or three numbers, not a full dashboard.
QA can propose process improvements from this data. One concrete experiment per retro beats a vague commitment to “improve quality next sprint.” Examples: add a staging smoke test, move mobile testing earlier in the sprint, or rotate exploratory testing between developers and QA.
Backlog Refinement
Refinement is the cheapest place to fix a bad story. QA helps size upcoming work by assessing testing complexity, identifying dependencies, and flagging environment needs early. A story that needs a new test environment discovered during refinement costs hours; the same story discovered in the sprint costs days.
QA often writes or co-writes initial acceptance criteria during refinement. This doesn’t mean QA owns the criteria forever, but having them drafted before planning makes estimates more accurate and prevents “we’ll figure out testing later” commitments.
Agile QA Workflow Models
There isn’t a single correct agile QA workflow. The three dominant models make different trade-offs, and the right one depends on your team size, product risk, and automation maturity. See our deeper breakdown of agile testing practices for sprint-based teams for a side-by-side view.
Embedded QA Model
One or more QA engineers sit inside the scrum team full time. They attend every ceremony, pair with developers, and own the testing plan for every story. The QA engineer is a permanent team member, not a rotating resource.
This model works best for high-risk products where a missed bug has serious consequences: healthcare, fintech, or anything with compliance requirements. It also works for teams building complex user workflows where exploratory testing catches what automation misses. The trade-off is cost: one QA per team scales linearly with headcount.
Shared QA Pool Model
A small group of QA engineers serves multiple scrum teams. They’re assigned to sprints based on workload and priority, and they may rotate between teams every sprint or two. Standup attendance is partial, and refinement involvement depends on capacity.
The shared pool works for early-stage startups with limited QA headcount and for mid-size companies with many small teams. The risk is obvious: QA context is lower, and the engineer loses the long-term relationship with any one product. Clear documentation and written test plans become mandatory, not nice-to-have.
Developer-Testing Model
Developers write all automated tests: unit, integration, and end-to-end. QA engineers focus on exploratory testing, test strategy, tooling, and process coaching. In this model, there may be only one QA engineer for the entire engineering organization, or none at all.
This model works for mature engineering teams with strong automation culture, high coverage, and disciplined code review. Google, Meta, and Spotify have all described variants of it publicly. It fails when teams adopt it to save money without the underlying engineering practices in place. The State of Agile Report from Digital.ai has tracked the slow shift toward developer-testing models, though dedicated QA roles still dominate most industries.
The QA Workflow From Story to Done
Most agile QA workflows follow the same shape regardless of which model above you pick. The details change, but the transitions are consistent. Here’s the canonical flow:
- Story moves to “In Development.” The developer picks up the story, reviews acceptance criteria with QA if needed, and starts work.
- Developer writes unit and integration tests: Tests run locally and in CI before the pull request opens.
- Pull request opens, automated tests run: CI executes the full test suite. Any failure blocks merge.
- Story moves to “In QA.” After merge, the feature deploys to a staging or preview environment.
- QA tests against acceptance criteria: The tester walks through each criterion, plus exploratory testing around edges.
- Bug found? File with full context, move back to “In Development.” Include screenshots, console logs, network activity, and environment details.
- All tests pass? Move to “Done.” The story is shippable.
The step that breaks most often is step 6. Bug reports without reproduction steps, logs, or environment data create days of back-and-forth. If you’re following our step-by-step Jira bug report guide, you already know the fields that matter. Tools that auto-capture context turn a 10-minute bug file into a 30-second one.
That’s the gap ShotMark fills. One-click capture of screenshots, browser console logs, network requests, and session replay sends a complete bug report to your issue tracker without the tester having to reconstruct anything. For open-source teams, ShotMark’s SDK ships as a library you can embed in your own tools.
Common QA-in-Agile Challenges
The same four complaints show up across agile teams of every size. Each one has a concrete fix.
“We don’t have time for testing in the sprint.” This usually means QA effort isn’t included in story points. Fix it in planning: size stories with testing included, and commit to fewer stories per sprint if the numbers don’t fit. Running a smaller, cleaner sprint beats running an overcommitted one where QA gets squeezed.
QA is always testing last sprint’s features: If QA work lags by a full sprint, the team is effectively working in waterfall with agile labels. The root cause is usually stories being “dev complete” but not “deployable” when they hit QA. Fix it by defining “ready for QA” strictly: merged, deployed to staging, smoke-tested.
Developers skip writing tests because “QA will catch it.” This is a culture problem, and it breaks any QA model. The fix is social: unit test coverage becomes part of code review, and PRs without tests get sent back. QA can advocate, but developers have to own the unit layer.
QA becomes a bottleneck at sprint end: When every story lands in QA on Thursday of a two-week sprint, the bottleneck is inevitable. The fix is continuous delivery of stories to QA throughout the sprint, not a lump at the end. See our sprint testing guide for concrete scheduling patterns that prevent the end-of-sprint crunch.
None of these fixes are technical. They’re workflow adjustments that any scrum team can make in one or two sprints. The Atlassian agile testing guide covers similar patterns with templates for teams using their tooling.
Making QA in Agile Work for Your Team
The QA engineer in agile teams isn’t a gatekeeper at the end of a pipeline. The role lives inside every ceremony, every story, and every pull request. Get the ritual mapping right, pick the workflow model that matches your risk profile, and treat bug reports as communication rather than paperwork. That’s most of the job.
ShotMark helps with the slowest part of that loop. When a tester finds a bug, the one-click capture of screenshots, console logs, network data, and session replay means no one spends 10 minutes reconstructing context. Join the waitlist at shotmark.dev if you want early access when we launch the open-source SDK.
Get new posts in your inbox.
One email when we publish: notes on QA, AI, and shipping faster. No spam, unsubscribe anytime.
