Most QA engineers show up to testing on day 9 of a two-week sprint. By then, the cost of every missed requirement is two more days to fix and retest. QA's highest-leverage point is backlog refinement, where asking about edge cases before development starts shapes what the developer builds, which requirements get written down, and what won't become a bug in production.
QA Is Not a Phase. It Is a Presence.
The clearest sign that a team understands Agile is how they answer this question: "Where does QA fit in our sprint?" The wrong answer is "the last three days." The right answer is "everywhere."
Consider a two-week sprint working on a checkout flow for an e-commerce app. The team is adding a discount code field. In a team doing it wrong, QA hears about this on day 9 when the developer marks the ticket "ready for testing." Three days to test and fix before the sprint ends.
In a team doing it right, QA is involved when the ticket is created. Before a line of code is written, the QA engineer has reviewed the acceptance criteria and asked: What happens if the code is expired? What if the user applies two codes? What if the discount makes the total negative? Those questions get answered before development starts, which means the developer knows what to build the first time. When the ticket arrives in testing on day 7, QA has already written test cases. Testing takes hours, not days. There is buffer for bug fixes.
This is not a process improvement. It is the intended design of Agile. The cross-functional team model exists precisely so that QA expertise is applied before code is written, not after.
Sprint Ceremonies: Where QA Work Actually Happens
Every Scrum ceremony is an opportunity. Most QA engineers use only some of them.
Backlog refinement is where QA has the highest leverage. This is the meeting where upcoming tickets get detailed before the sprint starts: acceptance criteria written, edge cases discussed, designs reviewed. QA's job here is to be the person who asks the questions that will become bugs if nobody asks them now.Picture a refinement session for a new user profile page. The acceptance criteria say: "User can update their name, email, and profile photo." A developer reads this and knows what to build. A QA engineer reads this and asks: What are the validation rules for the name field? Is there a character limit? What file formats are accepted for photos? What's the max file size? What happens if the user updates their email to one that already exists in the system? What if they try to upload a virus?
None of these are edge cases the QA engineer invented. They are requirements that weren't written down yet. Surface them in refinement and they become acceptance criteria. Skip refinement and they become bugs in production.
Sprint planning is where QA estimates. Not just development estimates, but testing estimates. A story that takes two days to build might take a day to test thoroughly, or it might take four. Automation work is separate from manual testing work. If QA doesn't speak up in planning, the sprint gets loaded with development work that physically cannot be tested in the time remaining. Daily standups are where QA communicates blockers early. The worst pattern: a QA engineer silently blocked for two days because a staging environment is broken, then raising it on day nine. The standup exists to surface this on day one. "I'm blocked. Staging is returning 500 errors on the payment service, I need that fixed to continue." The Scrum Master then owns removing that blocker. If you're not communicating blockers at standup, you're not using the ceremony correctly. Sprint retrospectives are where QA improves the process. Not complains about it, but improves it. There is a difference. "Stories always arrive in testing without enough detail" is a complaint. "Stories always arrive in testing without enough detail; I'd like to propose we require a test notes section on every ticket before it enters the sprint" is a retrospective contribution. QA engineers who use retros well gradually shape how the entire team operates.What "Done" Means From a QA Perspective
The Definition of Done is a team agreement about what conditions a ticket must meet before it is closed. Most teams have one. Many teams let QA define their portion of it poorly.
A common QA Definition of Done looks like: "Testing completed." That is not a definition. That is a vague gesture.
A better QA Definition of Done for a feature ticket: acceptance criteria tests written and passing in the test suite, exploratory testing completed with session notes logged, no open critical or high severity bugs, regression scenarios verified for affected adjacent features, and the ticket tested on the environments specified in the sprint agreement (staging, at minimum).
The discipline this creates is significant. When a developer marks something "ready for QA," you have a checklist. When you close a ticket, you can point to exactly what was done. When something breaks in production, you can trace which part of the DoD was not met. This is how QA work becomes auditable instead of just trusted.
For test tickets specifically (the tickets where QA is writing automation, not testing a feature), the Definition of Done should include: tests run in CI pipeline without flakiness across three consecutive runs, tests cover the scenarios documented in the ticket, and PR is reviewed by another QA or a developer familiar with the test framework.
A scenario from practice: a team had recurring arguments about whether an automated test count as "done" if it was written but running in an optional pipeline that didn't block merges. Defining the DoD explicitly resolved this. The test wasn't done until it was in the blocking pipeline. The team agreed. Arguments stopped.
The "Testing Last" Anti-Pattern and Shift Left
Shift-left testing means moving testing activities earlier in the development process. The phrase has been used enough that it has become meaningless in some teams: a slogan without practice. Here is what it actually means in a sprint context.
A team following shift-left testing does three things differently. First, QA writes test scenarios from acceptance criteria before development starts. Not to run them immediately, but so the developer can see exactly what will be validated. The developer codes to pass those scenarios. This eliminates an entire class of bugs: the ones where the developer misunderstood what "done" looked like.
Second, testing happens in parallel with development. When a developer finishes one sub-task of a story, that part goes to QA while development continues on the next sub-task. A login feature might have: form rendering, validation logic, API call, success redirect, error states. Test the form rendering while validation logic is being built. By the time development is complete, you've already tested 60% of the feature.
Third, QA is involved in code review for test coverage decisions. Not line-by-line code review (that's the developer's domain), but a review of: does this PR include tests? Do the tests cover the acceptance criteria? Are there paths that aren't tested?
The concern QA engineers often raise: "If I shift left and test earlier, I end up testing incomplete features and retesting everything." This is legitimate if you shift left without coordinating with developers. The fix is explicit handoff agreements. "Tell me when the happy path is working. I'll test that. Then tell me when error handling is done. I'll test that separately." Small handoffs beat one large handoff at the end.
Kanban vs Scrum: What the Difference Means for QA
The practical difference between Scrum and Kanban from a QA perspective comes down to cadence and WIP limits.
In Scrum, work arrives in batches defined by sprint planning. You have two weeks and a defined set of tickets. There are ceremonies and defined moments where QA's role is explicit.
In Kanban, work flows continuously. There is no sprint boundary. A developer finishes something and pushes it to the "Ready for QA" column. QA picks it up, tests it, and pushes it to Done. Another one arrives. Repeat.
For feature-rich product teams, Scrum gives QA better advance notice. You can see what's coming in the sprint and plan test coverage before tickets arrive. For support and maintenance teams (ones doing bug fixes, infrastructure work, and small improvements), Kanban often works better because sprints create artificial urgency that doesn't match the work type.
The risk in Kanban for QA is invisible load. In Scrum, if the sprint is overloaded, it's visible in planning. In Kanban, QA can quietly become the bottleneck: a stack of tickets accumulating in "Ready for QA" that nobody notices until the developer starts asking why their feature isn't released yet. WIP limits exist to prevent this. If your Kanban board has no limit on how many tickets can be in Testing simultaneously, you will eventually become the bottleneck.
A practical rule: set your QA WIP limit at two active testing tickets. Three if you're running automation and manual testing simultaneously. Beyond that, you're context-switching constantly and slowing down rather than speeding up.
QA in CI/CD: When There Are No Sprint Boundaries at All
Some teams, especially those running mature CI/CD pipelines, have effectively dissolved the sprint as a testing boundary. Code merges daily. Pipelines deploy to staging automatically. Releases go to production on a schedule or continuously.
In these environments, QA work happens at several points simultaneously.
At the pull request level, automated tests run before code merges. QA engineers own these suites: they define what gets tested in the pipeline, they handle test failures that block merges, and they triage whether a failing test is a real regression or a broken test. This is full-time work at scale.
At the staging deployment level, a broader regression suite runs after each deploy. QA monitors these runs and investigates failures. The discipline required here is triage speed: a failing staging pipeline needs a human decision within minutes, not hours, or the deployment queue backs up.
At the feature level, new features still require exploratory testing and acceptance validation. In a CI/CD team, QA coordinates directly with developers about deployment timing. "Deploy feature X to staging by Tuesday and I'll have it validated before the Wednesday release window."
The shift in this model: QA is no longer primarily a manual tester who writes some automation. QA is primarily an automation engineer who does manual validation for new features. If you're working toward roles in modern product companies, this is the direction the industry has been moving since 2022 and is the standard operating model in 2026.
Metrics That Actually Tell You Something
Most QA metrics are reported because they're easy to collect, not because they're meaningful. Test pass rate in isolation means nothing. If you wrote 50 tests that only test the happy path, a 100% pass rate tells you the happy path works. It doesn't tell you whether the feature is actually reliable.
Metrics worth tracking in an Agile QA context:
Defect escape rate is the percentage of bugs found in production versus bugs found before production. This is the core QA signal. If it's increasing sprint over sprint, something in your testing process is degrading. If it's decreasing, something is improving. Calculate it per sprint and trend it over quarters. Test cycle time is how long from "ready for QA" to ticket closed. This tells you whether testing is the sprint bottleneck. If average cycle time is three days and your sprint is ten days, you have a structural problem. If cycle time is six hours on average, your testing process is efficient. Bug discovery timing is when in the sprint bugs are being found. If most bugs surface in days 9-10, testing is being squeezed to the end. If bugs are distributed across the sprint, parallel testing is working. This metric requires you to log bug creation date, which most teams do automatically through their issue tracker. Flaky test rate is the percentage of your CI test runs with at least one test that fails intermittently without a code change causing the failure. Anything above 5% is a signal that your automated suite is becoming untrusted. Untrusted suites get bypassed. Bypassed suites are worthless.What not to over-weight: raw test case count, test coverage percentage without context, and bug count per sprint. A QA engineer who writes 200 shallow test cases looks more active than one who writes 50 deep ones. Coverage percentage depends entirely on what's being counted. Bug count per sprint fluctuates with feature complexity, not QA effectiveness.
How to Apply This Monday Morning
The gap between reading about Agile QA and practicing it tends to be specific habits. Here are five that have the highest immediate impact.
Before your next sprint starts, read every ticket in the backlog for the next sprint and write three questions about each one. Bring those questions to refinement or drop them directly in the ticket. You will find missing acceptance criteria every time.
In your next standup, if you are blocked or partially blocked, say so explicitly. Not "I'm working on the login tests." Say "I'm working on the login tests. I'm waiting on the dev environment to be redeployed with the new config, expected this afternoon." Specificity lets the Scrum Master act.
In your next sprint retro, come with one proposed process change. Format it as: "I noticed X happening three times this sprint. I'd like to try Y for one sprint and see if it improves." Small, time-bounded proposals get adopted. Vague complaints do not.
Add a test note field to your next ticket before a developer starts. Write two sentences: "Test entry point" and "Known edge cases to verify." This takes three minutes and eliminates most of the back-and-forth when the ticket arrives in testing.
If your team has a CI pipeline, look at the last 10 test runs and identify any test that failed intermittently. Log it as a flaky test ticket. Flaky tests are technical debt that erodes team trust in automation faster than almost anything else.
Agile done correctly makes QA more effective, not more pressured. The ceremonies exist so that problems surface early, when they're cheap to fix. The Definition of Done exists so that "done" means the same thing to everyone. The retrospectives exist so the process keeps improving. Use all of it, and the sprint cycle becomes a machine that produces reliable software instead of a deadline machine that produces stress.
→ See also: QA Automation Roadmap 2026: Essential Skills to Get Hired | CI/CD for QA: GitHub Actions, Jenkins, and GitLab Compared | Agile and Scrum for QA Engineers: What You Actually Need to Know
