QA in Agile
How testing fits a sprint — the QA role from grooming to the three-amigos session, testing inside the iteration instead of after it, QA criteria in the Definition of Done, and estimating testing effort.
5 questions
MiddleTheoryVery commonWhat QA criteria belong in a story's Definition of Done, and how does it differ from Definition of Ready?
What QA criteria belong in a story's Definition of Done, and how does it differ from Definition of Ready?
The Definition of Done is the team's shared checklist a story must meet to be shippable. Its QA criteria typically require acceptance criteria verified, planned tests passing, no open critical or major defects, and regression run. The Definition of Ready is the entry gate — a story starts only when its acceptance criteria and testability are clear.
Common mistakes
- ✗Reducing the Definition of Done to 'code merged' with no test criteria
- ✗Confusing the Definition of Done (exit gate) with the Definition of Ready (entry gate)
- ✗Treating the DoD as one person's checklist rather than a team agreement
Follow-up questions
- →Why should the Definition of Done be a team agreement rather than QA's alone?
- →What belongs in the Definition of Ready so a story is testable from the start?
JuniorTheoryCommonWhat is a three-amigos session, and what does QA bring to it?
What is a three-amigos session, and what does QA bring to it?
A three-amigos session brings three perspectives on a user story together — business (PO or analyst), development, and testing — to build shared understanding before coding starts. QA contributes the testing view: edge cases, acceptance criteria, and testability, so ambiguity surfaces early instead of during test execution.
Common mistakes
- ✗Thinking the three amigos are three developers or three testers, not business/dev/test
- ✗Treating it as a formal sign-off gate instead of a shared-understanding conversation
- ✗Believing QA only listens rather than raising edge cases and testability questions
Follow-up questions
- →Who are the three amigos, and can each role be filled by more than one person?
- →How does discussing a story up front reduce rework compared to reviewing at the end?
MiddleTheoryCommonWhen does testing happen inside a sprint, and how do you keep it from piling up at the end?
When does testing happen inside a sprint, and how do you keep it from piling up at the end?
Testing runs continuously through the sprint, not as a phase after development. QA tests each story as soon as it is buildable, rather than waiting for all coding to finish. This avoids the mini-waterfall where testing is crushed into the last days: slicing stories thin, pairing with devs, and automating regression keep testing in step with coding.
Common mistakes
- ✗Treating testing as a phase that begins only after all development is done
- ✗Deferring untested work to the next sprint or a separate hardening sprint
- ✗Not slicing stories thin enough for testing to start on partial work
Follow-up questions
- →What is a hardening sprint, and why is relying on one an anti-pattern?
- →How does testing a story as soon as it is built change how stories are sliced?
MiddleDesignCommonYour Scrum team is in sprint planning for a two-week sprint. The product owner brings a story to add a new payment method to an existing checkout flow, and the developers estimate it at 5 story points. As the only QA on the team, you must estimate the testing effort so the whole story still fits the sprint. Walk through how you arrive at a testing estimate: what you would ask about the story before committing to a number, which factors push testing effort up or down (new versus changed code, integrations, risk, existing automation coverage, test-data setup), how you account for regression and exploratory testing, and how you communicate the estimate and its uncertainty. Say what you would do if your estimate makes the story too large to finish within the sprint.
Your Scrum team is in sprint planning for a two-week sprint. The product owner brings a story to add a new payment method to an existing checkout flow, and the developers estimate it at 5 story points. As the only QA on the team, you must estimate the testing effort so the whole story still fits the sprint. Walk through how you arrive at a testing estimate: what you would ask about the story before committing to a number, which factors push testing effort up or down (new versus changed code, integrations, risk, existing automation coverage, test-data setup), how you account for regression and exploratory testing, and how you communicate the estimate and its uncertainty. Say what you would do if your estimate makes the story too large to finish within the sprint.
First understand the story — scope, acceptance criteria, and risk. Then weigh the effort drivers: new versus changed code, number of integrations, existing automation, and test-data setup. Add time for regression around the touched areas and for exploratory testing, not only the happy path. Give a range rather than a false-precise number and flag the uncertainty. If the story is too big for the sprint, propose splitting or descoping it with the PO instead of silently cutting testing.
Common mistakes
- ✗Using a fixed 'testing = X% of dev' ratio for every story regardless of risk
- ✗Leaving regression and test-data setup out of the estimate
- ✗Giving a single precise number instead of a range with stated uncertainty
Follow-up questions
- →How would you split the story if testing pushes it past the sprint's capacity?
- →Why give the estimate as a range rather than a single number?
SeniorDesignOccasionalYou are the only QA engineer on a Scrum team with six developers, shipping a release every two weeks. Every story flows through you for testing, and the backlog of finished-but-untested stories keeps growing toward the end of each sprint — you have become the bottleneck, and quality slips as you rush the final days. You cannot hire another tester. Describe how you would keep quality high without being the single point everything queues behind: how you would spread testing responsibility across the team, where you would invest your own limited time, what you would automate or bake into the Definition of Done, how in-sprint testing and three-amigos conversations help, and which risks you would consciously accept rather than trying to test everything yourself.
You are the only QA engineer on a Scrum team with six developers, shipping a release every two weeks. Every story flows through you for testing, and the backlog of finished-but-untested stories keeps growing toward the end of each sprint — you have become the bottleneck, and quality slips as you rush the final days. You cannot hire another tester. Describe how you would keep quality high without being the single point everything queues behind: how you would spread testing responsibility across the team, where you would invest your own limited time, what you would automate or bake into the Definition of Done, how in-sprint testing and three-amigos conversations help, and which risks you would consciously accept rather than trying to test everything yourself.
Stop being the only gate. Spread testing across the team: developers own unit and integration tests, and quality criteria go into the Definition of Done. Slice stories so testing starts as each is built — in-sprint, not end-loaded. Spend your own time where risk is highest: exploratory testing and coaching devs to test. Automate stable regression and use three-amigos sessions to catch ambiguity early. Prioritize by risk and accept low-risk gaps rather than testing all yourself.
Common mistakes
- ✗Trying to personally test every story and just working longer hours
- ✗Believing 100% automation removes the need for human testing or QA in planning
- ✗Pushing testing into the next sprint, creating a permanent testing lag
Follow-up questions
- →Which one change would you make first, and how would you measure it worked?
- →How do you decide which risks are safe to leave untested?
