Agile & Scrum Basics for QA
Prerequisites: You should already understand Testing Across the SDLC, including how Agile fits among the other SDLC models. Leads to: After this, you'll be ready for Verification vs. Validation and Static vs. Dynamic Testing.
Most working QA engineers today operate inside Scrum, not Waterfall — this module is about what that actually means for the day-to-day job, beyond "we test in short cycles now." Agile changes not just when testing happens, but what QA is expected to contribute to before there's anything to test at all.
Why This Matters
A team that treats Scrum as "Waterfall in two-week boxes." A team adopts Scrum in name — they have sprints, standups, and a sprint board — but QA still only gets involved once development finishes a story, exactly like the old process, just compressed into two weeks instead of three months. Stories arrive at QA underspecified, acceptance criteria are vague, and by the time a real ambiguity surfaces, there's barely a day left in the sprint to resolve it. The sprint ends with half the stories carried over, and the retro blames "not enough time for testing" — without anyone noticing that QA was never invited into the parts of the sprint where the ambiguity could have been caught early.
A team that actually practices Agile QA. A different team treats QA as part of every ceremony, not just sprint execution. QA is in backlog refinement, asking clarifying questions and helping write acceptance criteria before a story is ever pulled into a sprint. By the time a story reaches development, its Definition of Done is specific enough that both the developer and QA know exactly what "finished" looks like. Testing starts the moment a piece of functionality exists, not after the whole story is "done" from the developer's point of view. The same two-week sprint that broke the first team routinely finishes clean for this one — not because they work faster, but because ambiguity gets resolved on day one instead of day twelve.
Both teams "do Scrum." Only one of them uses it the way it's meant to work — with QA involved in shaping the work, not just verifying it afterward.
What Agile and Scrum Are, for a Tester
Agile is a mindset and family of values (from the Agile Manifesto) favoring working software, collaboration, and responding to change over rigid up-front planning. It's a philosophy, not a specific process.
Scrum is the most common concrete framework for practicing Agile: work is organized into fixed-length iterations called sprints (commonly one or two weeks), with a defined set of roles, ceremonies, and artifacts.
| Element | What It Is | Why QA Cares |
|---|---|---|
| Sprint | A fixed-length iteration (usually 1–2 weeks) producing a potentially shippable increment | Testing has to fit inside the sprint, not happen after it |
| Backlog Refinement | Ongoing session(s) where upcoming stories are clarified and estimated before being pulled into a sprint | QA's best opportunity to catch ambiguity before development starts — this is verification, applied inside Scrum |
| Sprint Planning | The meeting where the team commits to what will be built in the sprint | QA should weigh in on testability and risk before commitment, not after |
| Daily Standup | A short daily sync on progress and blockers | Where QA surfaces testing blockers early enough for the team to react within the sprint |
| Sprint Review | Demoing the completed increment to stakeholders | Where validation becomes visible — does the finished work actually satisfy the real need |
| Sprint Retrospective | The team reflects on what worked and what didn't | Where process gaps (like "QA only sees stories at the end") get named and fixed |
| Definition of Done (DoD) | The team's shared, explicit checklist for when a story is truly complete | QA should help define it, and every story is measured against the same bar — no negotiating "done" per story |
The most common misconception is that Agile testing means "testing faster." It actually means testing earlier and continuously — inside the same sprint the code is written in, often as functionality becomes available piece by piece, rather than waiting for an entire story to be code-complete before QA ever looks at it.
When QA Should Be Involved
QA's involvement in Scrum isn't limited to the days right before a sprint ends — it spans the whole cycle:
- During backlog refinement: reviewing upcoming stories for testability, asking what "done" looks like, and flagging ambiguity before a story is ever committed to a sprint — the same static, verification-style thinking from Verification vs. Validation, applied continuously rather than as a one-time gate.
- During sprint planning: raising known risk areas so the team scopes commitments realistically, rather than discovering mid-sprint that a story was riskier than assumed.
- As soon as a piece of functionality is available: testing incrementally throughout the sprint, not waiting for the entire story to reach "code complete" before starting.
- At the daily standup: surfacing blockers — an environment issue, an unclear requirement, a dependency on another team — while there's still time in the sprint to resolve them.
- At sprint review: helping validate that the increment actually satisfies the real need, not just that it passed the tests written against the ticket.
QA involvement should not be limited to a single phase near the end of the sprint — that pattern is just Waterfall's "testing happens last" habit, wearing a two-week disguise.
How This Works on a Real Project
A logistics company's QA engineer joins a Scrum team building a shipment-tracking feature. Over one sprint, their involvement looks like this:
Backlog refinement (before the sprint starts): The story as written says "show shipment status to the customer." The QA engineer asks what happens if a shipment has no tracking data yet, and what happens if the carrier's API is temporarily unavailable — neither is mentioned. The team adds both as explicit acceptance criteria before the story enters the sprint, turning a vague requirement into a specific, testable one.
Sprint planning: The team is about to commit to five stories. The QA engineer flags that one of them touches the same carrier-integration code that caused a production incident two sprints ago — a defect-clustering signal, echoing Software Testing Principles. The team agrees to scope that story more conservatively and pair a developer with QA on it directly.
Mid-sprint: As soon as the backend endpoint for shipment status is deployed to a test environment — days before the frontend work is finished — the QA engineer starts testing it directly, rather than waiting for the whole story to be "done." A missing-tracking-data edge case (one of the two scenarios added during refinement) turns up a real bug: the API returns a malformed response instead of a clean "no data yet" state. It gets fixed with four days left in the sprint, not discovered the day before release.
Daily standup: The QA engineer mentions that the staging environment has been down for half a day, blocking further testing. Because this surfaces immediately rather than being discovered on the sprint's last day, the team escalates it and gets it resolved within hours.
Sprint review: The finished feature is demoed to the product owner and two customer-support stakeholders. One stakeholder points out that "in transit" as a status label is confusing to customers who don't know if that means the package left the warehouse yet — a real validation gap that only surfaces by watching real people react to the finished thing, exactly the kind of gap Verification vs. Validation describes verification alone as unable to catch.
Retrospective: The team notes that involving QA in refinement caught two real issues before development even started, and agrees to keep doing it as standard practice, not a one-off experiment.
Common Mistakes
Mistake 1: Only involving QA once a story is "dev complete." This recreates Waterfall's core problem — testing pushed to the end — just inside a shorter time box. Ambiguity that could have been caught in refinement instead eats into the sprint's remaining days.
Mistake 2: Treating the Definition of Done as optional or negotiable per story. A DoD that changes story to story stops meaning anything — "done" has to be a consistent bar the whole team, including QA, agrees to and applies uniformly.
Mistake 3: Waiting for the whole story to be finished before testing any of it. Incremental testing as functionality becomes available catches defects while there's still sprint time left to fix them; waiting for full completion turns testing into a last-day scramble.
Mistake 4: Treating sprint review as a demo only, not a real validation check. If nobody at sprint review is actually asking "does this solve the real problem," the ceremony becomes a status update instead of the validation opportunity it's meant to be.
Best Practices
Practice 1: Bring QA into backlog refinement as standard practice, not an experiment. Catching ambiguity before a story enters a sprint is the cheapest possible time to catch it — this is Software Testing Principle 3 (early testing saves time and money) applied directly.
Practice 2: Help define — and hold the team to — a single Definition of Done. A shared, explicit DoD keeps "finished" from meaning something different depending on who's asked.
Practice 3: Test incrementally as functionality becomes available, not just at the end of a story. This surfaces defects while there's still time in the sprint to react, instead of compressing all testing into the final days.
Practice 4: Use retrospectives to fix process gaps, not just celebrate what went well. If QA involvement is consistently too late in the sprint, that's a concrete, fixable process issue worth naming explicitly in retro, not a recurring complaint to just live with.
Key Takeaways
- Agile is a mindset; Scrum is the concrete framework most teams practicing it actually use, built around fixed-length sprints and defined ceremonies.
- QA's most valuable involvement often happens before development — in backlog refinement and sprint planning — not just during test execution.
- Testing incrementally as functionality becomes available, rather than waiting for a whole story to finish, keeps defects fixable within the same sprint.
- A shared, consistently applied Definition of Done is what keeps "done" meaningful across a whole team.
- Sprint review is a real validation opportunity, not just a demo — it's where a feature meets real reactions from real stakeholders.
What You Just Learned
- The difference between Agile as a mindset and Scrum as a concrete framework
- Where in the Scrum cycle QA adds the most value, and why that's earlier than most teams assume
- How a logistics team's QA engineer caught real issues in refinement, planning, mid-sprint, and review — not just at the end
- Why "testing faster" is a misreading of Agile testing; "testing earlier and continuously" is the actual shift
Next: Verification vs. Validation
Related Topics
- Testing Across the SDLC — Where Agile sits among the other SDLC models this path already covered
- Software Testing Principles — Early testing and defect clustering, both applied directly to how QA operates inside a sprint
- Verification vs. Validation — Backlog refinement as verification; sprint review as validation
- Risk-Based Testing Fundamentals — The same risk-flagging instinct QA brings to sprint planning
Interview Questions
Q1: How is testing different in Agile compared to Waterfall?
What to look for: A candidate who says testing happens earlier and continuously throughout the sprint — not just "it's faster" or "we do it in smaller batches," which misses the actual shift in when and how QA gets involved.
Q2: What would you do if stories consistently arrive to QA without clear acceptance criteria?
What to look for: A candidate who proposes getting involved in backlog refinement to fix the root cause, not just working harder to interpret vague stories after the fact.
Q3: What's the difference between a Definition of Done and an acceptance criterion?
What to look for: Recognition that Definition of Done is a consistent, team-wide bar applied to every story, while acceptance criteria are specific conditions for one particular story — a candidate conflating the two hasn't worked with both in practice.
Glossary
Sprint: A fixed-length iteration, commonly one or two weeks, during which a Scrum team builds a potentially shippable increment of the product.
Backlog Refinement: An ongoing activity where upcoming stories are clarified, estimated, and made ready for a future sprint — QA's earliest opportunity to catch ambiguity.
Definition of Done (DoD): A team's shared, explicit, consistently applied checklist for when any story is considered truly complete.
Sprint Review: The ceremony where the team demonstrates the sprint's completed work to stakeholders — a real opportunity for validation, not just a status update.