"When does QA happen?" is the wrong question, and it usually produces the worst answer: at the end. After working inside Scrum teams for a while, I have stopped thinking of testing as a phase of the agile sprint and started thinking of it as a thread that runs through every ceremony — with one place it deliberately does not belong.
Refinement: where testing actually starts
The highest-leverage QA work happens before a line of code exists. In backlog refinement my job is to ask testability questions: What should happen when this fails? How will we verify it on a real device? What does this screen look like for an RTL user? Is there a way to reach this state in a test environment, or will testing be blocked waiting for data? Each answered question becomes an acceptance criterion. Each unanswerable one is a signal the story is not ready. Shift-left is not a tool you buy — it is QA showing up to refinement with questions and the standing to ask them.
Sprint start: a test plan measured in risks, not documents
At planning I sketch a short test approach per story: what gets automated, what gets exploratory time, which stories touch risky areas like payments or data migration and deserve extra attention, and what test data or accounts must be prepared now so testing is not blocked on day eight. All of it fits in a comment on the JIRA story. The goal is simple: when a story lands in "ready for test," nothing about testing it is a surprise.
During the sprint: automate in-sprint, not next sprint
Automation written a sprint later is written against a fading memory of the feature and a backlog that has already moved on — in practice, much of it never gets written at all. The practice that changed the most for my team was making automation part of the story's definition of done. When I wired our smoke and regression suites into GitHub Actions, in-sprint automation became the default: each story's Maestro flows joined the suite while the feature was fresh, coverage grew continuously instead of in catch-up batches, and regression testing time dropped by roughly half. The suite runs on every pull request, which means developers see test failures minutes after introducing them — while the change is still small enough to reason about.
Demo and reporting: QA's visible work in the agile sprint
QA belongs in sprint demos — sometimes demoing what was tested and what was found, not only what was built. An edge case that was caught and fixed is a legitimate demo item; it shows stakeholders what quality work looks like. And at release time, QA's deliverable is a readiness report, not a verdict: here is what was covered, here is what was not, here are the open risks and their severity. The decision to ship belongs to the whole team; QA's job is to make sure it is an informed one.
Where QA does not fit: the final gate
The anti-pattern is familiar everywhere. Developers finish everything by day eight, then throw it over the wall for testing in the last two days. The sprint ends with untested work, exhausted testers, or both — and quality becomes one person's bottleneck instead of the team's shared property. The fixes are structural, not motivational: stories flow to test continuously through the sprint, work-in-progress limits stop five stories arriving at once, developers run the smoke suite themselves before handoff, and "done" explicitly includes tested. A story that is not tested is not done — and that is the team's problem to solve, not QA's failure to absorb.
Takeaway: if testing consistently piles up at the end of the sprint, do not ask QA to test faster — change the flow. Smaller stories, delivered continuously, tested and automated in-sprint, will fix what overtime never will.
QA fits everywhere in an agile sprint except the place teams usually put it: the end.