What the QA in Scrum module actually covers
Scrum has no tester accountability, and that single fact causes more confusion than any other part of the framework for people who came into agile delivery through a QA career. The Scrum Guide lists Developers, and everyone building the Increment is a Developer, whatever their specialism. That is not a demotion. It means quality is not a stage that happens after the work, owned by someone who was not in the room when the decisions were made.
In a team that has absorbed this, testing starts at refinement. The tester is the person asking what happens with an empty list, a duplicate submission, a timezone boundary or a partial payment, and asking it before anyone writes code. The acceptance criteria get sharper because someone in the room thinks in failure modes. The Definition of Done gets teeth because the same person keeps asking what evidence proves an item is finished.
The failure pattern is easy to recognise. Work piles up unfinished until day eight, then lands on one person who tests everything under pressure while the Sprint Review clock runs down. Nothing about that is a testing problem. It is a flow problem the team can see in its own board if anyone looks. The module treats the day nine pile-up as the diagnostic it is, then works through what actually shifts it: smaller slices, pairing during development, agreed automation ownership and a Definition of Done that includes the checks nobody wants to run by hand for the twentieth time.
The module also covers the harder conversations. What to do when a stakeholder wants a release that fails a Done criterion. How to talk about risk without becoming the person who says no. When exploratory testing beats another automated assertion. Where a specialist genuinely helps, and where a specialist becomes a queue the rest of the team plans around.
Mistakes teams make with this material
Development for eight days, testing for two. The Sprint boundary hides the handover, but the handover is still there, and any defect found late has nowhere to go except the next Sprint.
If one person owns quality, the rest of the team stops thinking about it. The Definition of Done belongs to every Developer, and so does the work of meeting it.
A suite nobody trusts is worse than a smaller one that runs green and means something. Flaky tests get skipped, and skipped tests get deleted, usually the week before they would have caught something.
Counted defects become negotiated defects. The number goes down and the product does not get better.
Questions people ask
Is there a QA role in Scrum?
No separate accountability, no. People with testing expertise are Developers on the Scrum Team. The skill matters enormously, the separate lane does not.
Who owns the automated test suite?
The Developers, collectively. A tester may write most of it, but if only one person can fix a red build, the team has built a dependency it will trip over during holidays and handovers.
How do we stop testing piling up at the end of the Sprint?
Slice smaller, limit how many items are in progress at once, and make Done mean tested. Most day nine pile-ups are a work in progress problem wearing a testing costume.
A question from this module's assessment
One sample question with the reasoning, so you can judge the level before you start. The rest of the assessment stays inside the module.
Under the 2020 Scrum Guide, what is a dedicated tester's accountability on a Scrum Team?
- Quality Assurance Lead
- Developer, like everyone else building the Increment
- A sub-role reporting to the Scrum Master
- Product Owner delegate for quality
The Scrum Guide recognises one accountability for everyone creating the Increment: Developer. Testing skill remains, the separate role does not.