1.Why The QA and Tester Role in Scrum is worth getting right
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.
2.How it works in practice
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.
3.Role reality
The 2020 Scrum Guide has one accountability for anyone building the product: Developer. This is what that means once the Sprint starts.
| Textbook theory | Delivery reality |
|---|---|
| QA is a separate function that verifies work at the end. | There is no QA accountability in Scrum. A tester is a Developer whose deepest skill happens to be finding out whether something works. |
| Quality is checked before release. | Quality is built in from refinement. The cheapest defect to prevent is the one caught while writing acceptance criteria, not the one caught in a test pass. |
| A QA column on the board shows quality is taken seriously. | A QA column is a mini waterfall inside the Sprint. It creates a handoff, a queue, and feedback that arrives after the decisions that caused the problem. |
| The Definition of Done is a QA checklist. | It belongs to the whole Scrum Team. If only the tester enforces it, it is not actually the team's Definition of Done. |
| Automation replaces the need for testers. | Automation replaces repetitive execution. It does not replace risk analysis, exploratory testing or the judgement to say this is not Done. |
4.Core delivery pillars
Four habits that move quality earlier without slowing the team down.
Sitting in refinement and asking what would prove this wrong is the cheapest test you will ever run. Do it before the item enters a Sprint, not after.
Pairing with a Developer on a test before implementation removes an entire feedback loop. The defect never exists rather than being found later.
This is not Done is a Scrum Team decision, not a QA verdict handed down at the end. Everyone should be able to say it and mean it.
Automate regression and repetitive checks so human attention goes to exploratory testing, risk analysis and edge cases a script would never think to try.
5.Quality signal metrics
Numbers that show whether quality is being built in early, tracked by the whole team.
Issues caught before the item ever enters a Sprint. The highest-leverage number on this list.
Issues that reach production. Rising escapes point at a broken Definition of Done, not a weak tester.
How long finished code waits before verification. A growing queue signals a handoff, not a Sprint problem.
Share of repeatable checks automated. Freeing time for exploratory testing that a script cannot do.
6.Situations you will be asked to handle
The module puts you inside 2 decisions rather than asking you to recognise the right answer on a list. Each one is a situation practitioners meet, with several defensible options and consequences that follow from the one you pick. The scenarios below are the shape of the judgment the subject demands.
- Lesson 34.3: Game - Refinement Edge-Case Spotter
- Lesson 34.6: Game - the Day-9 code dump dilemma
7.Common mistakes and why they fail
Running a mini waterfall inside the Sprint
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.
Treating the tester as the quality department
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.
Automating everything that moves
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.
Reporting defect counts upward as a score
Counted defects become negotiated defects. The number goes down and the product does not get better.
8.Questions worth asking before you commit time to this
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.
9.What to remember
- Why there is no QA accountability in Scrum, and what replaces it
- Quality practices that move testing earlier instead of later
- A situational matrix for the calls a quality-minded Developer gets judged on
10.Where this sits in the Scrumling course
For QA Engineers, Testers and Developers: move from end-of-Sprint gatekeeper to a Developer accountable for quality from refinement onwards.
About 85 minutes of lessons and decision scenarios.
- Lesson 34.1: The tester identity in Scrum
- Lesson 34.2: Shift-left quality and Backlog refinement
- Lesson 34.4: In-Sprint testing strategy
- Lesson 34.5: Enforcing the Definition of Done and integrating automation
- Lesson 34.3: Game - Refinement Edge-Case Spotter
- Lesson 34.6: Game - the Day-9 code dump dilemma
Assessment: The QA and Tester Role in Scrum quiz