Not always. What an agile team always needs is testing done by someone other than the person who wrote the code, with time set aside for it. Whether that someone should be a dedicated tester depends on what a failure would cost, how much of the checking is automated and whether anybody else is placed to say what correct looks like. On a small team building a low-risk internal tool, the answer can be no. On a system that handles money, personal data or a workflow the business cannot run without, the answer is usually yes, even if only part-time.
Why the question comes up
Agile methods do not name a tester role. The Scrum Guide, whose current edition is dated November 2020, describes a team made up of one Scrum Master, one Product Owner and Developers, and says that within it “there are no sub-teams or hierarchies”. The words tester and testing do not appear anywhere in the document.
That is sometimes read as “agile teams do not have testers”. The guide says something different. It makes the Developers as a group accountable for quality, through an agreed Definition of Done that every piece of work must meet before it counts as finished. “Developers” in Scrum means everyone who helps build the product, and that can include a person whose skill is testing. What the guide removes is the separate test department that receives work at the end. The work itself remains.
The other source of the idea is the large online services that are said to run with few testers. Where that is true, it is because they can release a change to a small share of users, watch live monitoring and reverse the change within minutes. A business system used by one company, with a month-end deadline and an accounts package attached, has none of that protection. A fault goes straight to the people doing the work.
What a dedicated tester adds
Independence. The author of a piece of code tests that it does what they meant. They are poorly placed to notice that what they meant was wrong, because the same assumption sits behind both the code and the check.
A different habit of mind. Developers build things to work. A good tester looks for how they fail: the field left blank, the steps done in the wrong order, two people editing the same record, the back button pressed halfway through a payment.
Exploratory testing. This is unscripted investigation by a person who is curious and knows the system. Automated tests check what somebody anticipated. Exploratory testing finds the things nobody did.
Memory of the whole system. A tester who has been with a product for a year knows where it tends to break and which distant screens share code with the one being changed. That knowledge is the core of regression testing, the checking of things that were not supposed to change.
Protected time. When a deadline presses, a developer’s testing is the first thing to shrink. A tester’s hours are reserved for it.
When a team can do without one
A team can share the testing among its members when most of these are true:
- the developers review and test each other’s work as a routine, not as a favour;
- there is an automated test suite that runs on every change and is trusted;
- releases are small and can be reversed quickly;
- the product owner or real users try each feature during the sprint in which it is built;
- a fault is cheap, meaning it would be noticed and put right the same day.
Under those conditions the testing is still being done. It has been spread across the team and the tooling.
When you need one
The case for a dedicated tester gets stronger as these apply:
- the system handles payments, stock, payroll or regulated data;
- it connects to several other systems, each of which can fail in its own way;
- permissions are complicated, so that what one user sees must be hidden from another;
- users keep reporting that a fix in one place broke something elsewhere;
- nobody on the business side has time to try new features as they are built.
One situation deserves its own mention. An older system with no automated tests has nothing checking it except people. We meet this regularly when taking over software built by someone else: no tests, no specification, and nobody left who remembers what every screen is for. Until automated checks have been built up around the important calculations and integrations, every release needs a person to work through the key workflows on a copy of the system. That is a job, and it needs someone whose job it is.
The choice is not all or nothing. The common arrangements look like this.
| Arrangement | Suits | What to watch for |
|---|---|---|
| Developers test each other’s work | Small teams, low-risk systems, good automated tests | Testing squeezed out under deadline |
| A tester shared between projects | Most small business systems | The tester arriving too late in each sprint |
| A full-time tester in the team | Larger or higher-risk systems, or little automation | Developers leaving quality to the tester |
| An analyst who also tests | Projects where unclear requirements are the main risk | Two jobs competing for one person’s time |
The tester only you can supply
Whatever the supplier’s team looks like, one kind of testing belongs to the client. A supplier’s tester can check a feature against the written requirement. Only someone who does the work can say whether the requirement was right in the first place.
For each workflow that matters, name a person in your business who uses it and can confirm it behaves correctly. Give them an hour or two in every sprint to try what has been built. Small, regular checks find misunderstandings while they are cheap to correct. A single acceptance phase at the end finds them when the budget has gone. On a system with no specification this named person is the nearest thing to one, and no amount of testing skill on the supplier’s side replaces them.
How these checks fit into the rhythm of a sprint is covered in our article on integrating quality assurance with agile development.
Questions to ask a supplier
- Who tests a change, other than the person who wrote it?
- Is that person involved from the start of each sprint, or only once the code is finished?
- What is checked automatically on every change, and what is checked by hand before a release?
- What does your definition of done say about testing?
- What will you need from our staff, and for how many hours in each sprint?
There are more in our list of questions to ask a software supplier.
If you already have a team in place, there is a simple check you can make yourself. Take the last five faults your users reported. If most of them would have been found by someone trying the feature for ten minutes before release, the team needs more testing time than it currently has, whoever ends up supplying it.