Role of tester in agile teams: what changes and what does not

What changes when a tester joins an agile team

Three things stop. The tester stops receiving finished software to test at the end of a phase. The tester stops being the person who says a release may or may not ship. And the tester stops writing a test plan that nobody else reads. Three things start. The tester is in the room when a story is written and asks the questions that would otherwise become defects. The tester works on the same story as the developer, on the same day, often at the same desk. And the tester becomes the team's specialist in how to know whether something works, which is a skill the whole team uses.

What does not change matters just as much. Test design techniques, boundary thinking, risk-based prioritization and clear defect reports are as valuable in a two-week sprint as in a six-month phase. Lisa Crispin and Janet Gregory call this the whole-team approach: quality is everyone's job, and the tester is the person who makes that possible rather than the person who does it alone.

A tester's week inside a two-week sprint

The honest answer to where the hours go is that a good agile tester spends less than a third of the week executing tests. The rest is spent preventing the need to. A workable split for a tester on a team of five developers, in a ten-day sprint, looks like the bars below. The numbers are a starting point to argue with, not a rule.

Monday is planning: the tester walks through each candidate story and names the riskiest one out loud. Tuesday and Wednesday are refinement and pairing; two or three hours in the three amigos sessions produce the examples that become acceptance tests. Every day, as stories reach done-from-development, the tester runs a charter against them: a 60 to 120 minute exploratory session with notes. Automation work fills the gaps and keeps the pipeline green. Thursday of week two is demo preparation, which mostly means confirming the demo path actually works. Friday is the retrospective and the risk conversation for the next sprint.

The four kinds of work that fill the week

• Prevention. Questions in refinement, examples written before code, acceptance criteria that can be checked. One clarified requirement saves more time than any test finds.
• Investigation. Exploratory sessions on finished stories, focused on what the automated checks cannot see: usability, data edge cases, integration surprises, and the thing nobody thought to specify.
• Automation stewardship. Owning the strategy: what runs where, how long the suite may take, which checks are worth keeping. The tester writes some checks and reviews many. A team that makes the tester write every script has recreated the automation silo.
• Information. Telling the team, in plain words, what is known and not known about the product right now. A red board, a list of open risks, a two-minute summary at stand-up.

Anti-patterns: mini-waterfall and the gatekeeper

The most common failure is the sprint that contains a waterfall. Developers code for seven days, hand everything to the tester on day eight, and the tester has two days to test ten stories. Every sprint ends with a rush, a queue of defects, and stories carried over. The fix is mechanical: limit work in progress so a story is tested before the next one starts, put testing in the definition of done, and make the developer of a story pair on its testing rather than move on. A team with three stories in test and none in development has the ratio right.

The second failure is the tester as gatekeeper. When one person signs off releases, the rest of the team stops caring about quality because someone else is paid to. Move the decision to the definition of done, which the whole team owns, and make the tester the person who supplies evidence rather than the person who says yes or no. A third pattern, quieter than the others, is the tester who only automates. The pipeline is green and nobody has used the product with fresh eyes for weeks. Continuous delivery does not remove exploratory work; it makes room for it (see continuous testing).

Ratios and staffing

One tester for every three to five developers is the range most teams settle into. Below one to three, testers run out of finished work and drift into writing documents. Above one to five, exploratory coverage collapses and the tester becomes a scheduler of other people's testing. Teams that share a single tester across two squads should expect that person to test half as much and coach twice as much, and should plan for it rather than discover it. Where testers are scarce, the whole-team approach is not a slogan but a necessity: developers run charters, product owners check examples, and the tester teaches both.

Career paths from the agile tester role

Because the agile tester touches requirements, code and operations, the role branches in several directions. Toward the product: testers who are good at asking what the story is for become product owners or business analysts. Toward the code: testers who own the pipeline become automation architects or developers in test, leading the automation strategy across teams. Toward the organization: testers who coach several squads become quality coaches, test leads at program level, or agile coaches with a quality specialty. The skill that carries across all three is the habit of asking how we will know, early enough that the answer changes the plan.

Agile has been a recurring theme in the testing press for nearly two decades; issue 7 of the magazine (September 2009) took it as a theme and appears to have been cited by at least one developer-platform blog for that reason. The archive page for issue 7 lists what was covered at the time.

This guide is part of the agile testing hub. It is best read alongside exploratory testing and definition of done, which cover the neighbouring questions.