The Agile QA Process: What QA Actually Does Every Sprint

A QA lead moving from a waterfall shop to an agile one once asked a very practical question in her first week. What am I actually supposed to do on a Tuesday when there is no finished feature to test yet. That question rarely gets a straight answer, because most agile QA process writing stays philosophical. It explains why continuous testing matters rather than what a QA person concretely does sprint over sprint. This post answers the operational version of the agile QA process question. It walks through what QA does in refinement, development, and review each sprint. It closes with how a tool like Tesbo actually supports that workflow, without overselling what it does.

What is the agile QA process?

The agile QA process is the set of activities a QA person or team runs continuously through a sprint. It replaces the single block of testing that happens after development finishes in a waterfall process. In waterfall, QA typically gets a fixed testing phase once development is declared complete. That phase often lasts days or weeks depending on scope.

In an agile process, there is no separate testing phase at all. QA work is threaded through refinement, development, and review. It happens in parallel with the rest of the sprint rather than after it. A QA person on an agile team touches a story multiple times across the sprint instead of once at the end.

Consider a ten day sprint at a 15 person product team. In waterfall, QA would see the finished feature on day eight and have two days to test everything. In an agile QA process, that same QA person reviews the story on day one, drafts test cases by day three, and starts executing them in pieces from day four onward.

The role of QA in an agile project

QA involvement follows the sprint from start to finish rather than clustering at the close.

• During refinement: a QA person reviews upcoming stories, checks whether acceptance criteria are specific enough to test, and flags gaps before the story is committed to a sprint.
• During development: QA drafts test cases as acceptance criteria settle. QA starts executing them against pieces of the feature as they become available, rather than waiting for the whole story to be marked done.
• During review: QA confirms the demonstrated functionality actually matches what was tested, and flags anything demoed that has not yet been verified.
• During retro: QA raises where testing slowed the team down or where a bug slipped through, so the next sprint adjusts.

This is a fundamentally different rhythm than waterfall. There, QA's involvement is a single long stretch at the end rather than four touch points spread across two weeks.

Principles behind agile QA

A handful of ideas sit underneath the day to day workflow.

• Whole team quality ownership: quality is not QA's job alone. Developers write and maintain their own unit tests, and product owners write testable acceptance criteria.
• Continuous testing: testing happens throughout the sprint rather than in a dedicated phase.
• Fast feedback: a bug caught on day two of a sprint costs far less time and coordination to fix than one caught on day nine.
• Tight collaboration with developers: QA and developers talk through edge cases during development, not after a build is handed over.

The steps of the agile QA process across a sprint

A typical sprint has four practical steps for QA.

First comes story refinement and acceptance criteria review. QA reads each candidate story before it is committed. QA asks pointed questions if the criteria are vague. A story that says the checkout should handle errors gracefully gets pushed back. It needs to say something testable instead, like the checkout should show a specific error message when a card is declined.

Second comes test case design alongside development. As soon as acceptance criteria are locked, QA starts writing test cases, often before the code exists. Test cases end up ready the moment a feature branch is ready to test, instead of QA starting design work only after development finishes.

Third comes execution during the sprint. QA runs the drafted test cases against the feature as it becomes testable, in pieces rather than all at once. A five person QA team on a fortnightly release might test the payment form validation on day four, once that piece is built, rather than waiting until day nine when the whole checkout flow is done.

Fourth comes regression coverage before release. Once new functionality passes, QA runs a regression pass covering existing functionality the new change could have affected. This catches the kind of side effect that a narrow focus on the new feature alone would miss.

What agile QA looks like with Tesbo

A lot of what makes the agile QA process actually work in practice comes down to whether test cases stay connected to the requirements they were written for. Tesbo supports that specific piece. It manages and documents test cases, and it lets a team keep a record of which requirement a given test case traces back to.

That traceability matters most exactly where the four step process above tends to break down. When a story's acceptance criteria change mid sprint, a QA lead needs to see which test cases were written against the old criteria. They can then update those cases directly, rather than discovering the gap after release.

Picture a 900 test case suite spread across a dozen features. Without traceability, a change to one requirement means manually hunting through old documents to find every affected test case. With traceability in place, that search takes minutes instead of an afternoon.

Tesbo does not execute tests or run automation. It does not replace a CI pipeline or an automated test runner. What it does is keep the documentation side of the agile QA process organized: the test cases themselves and their link back to requirements, as the team moves through refinement, development, and review each sprint.

Best practices for tightening an agile QA process

A QA lead introducing or improving this process on their team should focus on a few concrete habits.

• Get QA into refinement as a standing invite, not an occasional one, so acceptance criteria get tested for testability before a story is committed.
• Write test cases as soon as acceptance criteria settle, not after the code is done, so execution can start the moment a piece of the feature is ready.
• Keep a regression pass in the schedule for every release, even a small one, since side effects on existing functionality are easy to miss when the whole team is focused on the new feature.
• Review at retro specifically for where testing slowed things down or where something slipped through, and adjust the next sprint's plan based on that, not just on gut feeling.

None of these steps remove the need for planning or documentation. They shift when that planning happens. It spreads across the sprint instead of holding until the end, which is the entire point of an agile QA process in the first place.