05 Nov 2026 Agile testing: what a tester does in a Scrum team, sprint by sprint

In short: Agile testing means testing is part of every sprint, not a phase at the end. The whole team owns quality, and the tester brings test design and risk thinking to it. A tester helps sharpen stories before the sprint, tests work as soon as it’s done, and makes sure the regression set keeps up. Without automation, that rhythm breaks within months.

Many teams work in sprints, but test like they did before. Developers build for eight days, and testing gets the last two. Every sprint ends in a rush, and unfinished testing slides into the next one. On paper the team is agile. In practice there’s a small waterfall inside every sprint. Agile testing is how you get out of that, and the tester’s role is where it starts.

What is agile testing?

Agile testing is testing that happens throughout every sprint, by the whole team, so each piece of work is really finished when the sprint ends. It follows from how Scrum defines “done”. The Scrum Guide says the work only counts as an increment when it meets the team’s definition of done, the agreed list of quality checks. If testing isn’t on that list, “done” just means “built”. In agile testing, a tester doesn’t wait at the end of a line. They work alongside developers and the product owner from the first conversation about a story. Developers write unit tests for their own code. The product owner knows what the business needs. The tester brings what the others often lack time or training for. That means thinking up the cases that will break it, judging risk and checking that the whole works together. Quality belongs to the team. Test design and risk thinking are the tester’s craft.

That idea goes back to the Agile Manifesto: working software is the measure of progress. Untested software isn’t working software yet.

What does a tester do during a sprint?

A tester’s work is spread across the whole sprint, not saved for the end. Each moment in the sprint has its own job. Before work starts, the tester helps make stories testable. During the sprint, they test each story as soon as it’s ready and automate what needs to keep working. At the end, they help the team decide whether the work is really done. This table shows the usual rhythm.

Not every tester does all of this alone. In a team with strong developers, much of the test automation may sit with them. The tester then guards the test design and the overall picture.

Where does testing in a sprint usually go wrong?

It goes wrong in three predictable ways, and they often show up together. None of them is about lazy people. They come from how the work is planned. If you recognise one, the fix is usually in the planning, not in working harder. These are the three.

• A small waterfall inside the sprint. Stories are finished late, so all testing lands in the last days. Anything that doesn’t fit moves to the next sprint.
• One tester for several teams. The tester runs from one stand-up to the next, and refinement is the first thing they skip.
• Regression that can’t keep up. Every sprint adds features that need checking again next time. Done by hand, the regression round grows until it eats the sprint.

The third one sneaks up on teams that do have automation. In conversations we often hear the same story. Coverage stalls a few months after rollout, because fixing old tests eats the time meant for new ones. A broken test gets skipped “just for now”, and nobody comes back to it. A year later, nobody knows whether to trust the coverage number. Does testing feel like the brake on your team? Our post on why QA gets called the bottleneck looks at the flow of work around it.

How does test automation keep the sprint rhythm going?

Automation is what makes it possible to test everything again every sprint without the work growing each time. The rule is simple. When a story is done, the checks that guard it go into the automated regression set, in the same sprint or the next. Then the checks run by themselves every night. The tester’s time goes to new work, exploring and talking with the team, not to repeating last month’s checks by hand. Our guide to regression testing covers what to automate first.

Our Financial Institution case shows what this looks like inside a Scrum team. Our consultant professionalised automated functional testing for new front-end applications for insurance sales. Fitnesse supported acceptance testing and the collaboration between business and development. Selenium, Protractor and SoapUI covered the browser, the front end and the APIs. Automated tests were designed for the critical functions, so the team could keep testing them every iteration.

Two trade-offs are worth naming. Not every team needs a full-time tester. A small team with developers who test well may need one for a few days a week, as long as someone owns test design. And automation never covers everything. Exploratory testing finds what no script checks, and acceptance testing by business users decides whether the work fits how they really work. Both stay human work.

What this means for your team

Look at your last three sprints. When did testing start on each story, and how much of the regression was still done by hand? If testing always lands in the last days, the problem is the rhythm, not the people. Make testing part of the definition of done. Bring a tester into refinement. And plan the automation of finished work as part of each story.

That works best with a tester who knows how to do this inside a team. Through our QA & Testing Solutions, our test consultants join your team, from test strategy to hands-on testing, in your tools and your sprints. “The testers blend very well into our projects”, wrote Peter van Lint of Technolution on our homepage. He added that their advice and participation bring automated and manual testing to a higher level. If the growing regression set is the bigger problem, our Test Automation as a Service runs and maintains it alongside your team.

A first step for this week: add one line to your definition of done. For example: “the checks for this story are in the automated regression set”.

Frequently asked questions

Does a Scrum team need a dedicated tester?

Not always. The Scrum Guide doesn’t name a tester role; the team as a whole delivers a done increment. But someone needs the skill and the time for test design and risk thinking. In many teams that works best with a tester.

Who is responsible for quality in a Scrum team?

The whole team. Developers test their own code and the product owner checks it meets the need. The tester brings test design, risk analysis and the view of the whole. The definition of done makes it concrete.

How many testers do you need per team?

There’s no fixed number. It depends on how much changes per sprint, how risky it is and how much regression is automated. Teams with good automation need fewer people for repeat checks, and more time for exploring.

Should testing happen in the same sprint as development?

Yes, as far as possible. A story isn’t done until it’s tested. Testing a sprint later means bugs come back when developers have moved on, and fixing them costs more.