Why Development Projects Go Wrong #3 - We Don't Need Testers

Many software development teams contain people that focus not on building the software, but on testing what others have built. Having people like this on the team is generally considered “best practice” but occasionally you encounter a team without them. There are a number of arguments as to why you shouldn’t have testers. All of which are wrong, in my opinion.

1. Having Testers Will Make the Developers Lazy

The argument goes that once developers know someone has got their back, they will get sloppy and the overall quality of what the team produces will stay the same.

It’s true that on some teams, testers are thought of as cleaning up after the developer’s mess and that developers do sit back as a result. But I would argue this is not an inherent problem with testers and more an issue of poor management and culture.

Testers must be thought of as equal stakeholders in the development process. If a tester suspects a developer has been sloppy, they should raise this with the developer's manager and cite specific examples.

Once their status on the team is assured, testers become powerful advocates for quality, holding developers to account for what they produce. Its possible to go too far and create animosity between developers and testers, but when you get the culture just right, testers actually make developers more conscientious, not less.

2. The Developers Should be Testing What They’ve Done

This argument says that, developers should be able to check the work that they’ve done themselves, so you don’t need separate testers.

There are two things wrong with this.

Firstly, testers are a little easier and cheaper to hire, so why tie up developers with work that testers could do.

More importantly though, testing requires a very different mindset from development. I’ve lost count of the number of times I, as a developer, have looked at code and sworn blind that a particular thing is impossible and cannot happen, only to find that a tester has reproduce that exact behaviour later on.

Developers are blinkered by what they think they know about the code, and just don’t have the headspace to attack a system with a critical and pessimistic eye. They are like the archetypal mad scientist in old movies; too focused on the detail and wonder of what they’ve created to be able to step back and see the potential problems.

3. We Wouldn’t Have Enough Work for Them.

As a general rule, effective testing will take about 40-50% of effort that’s gone into development. The level of configurability in the code you write will have an impact. As will the amount of data setup that’s needed and the complexity of the process. But in general, start with an assumption of 40-50% and go from there.

By that logic, you should hire 1 testers for every 2 developers. On a small team it's possible that the testing is only a small part of someone's job. This can work, but testing is definite skill in itself, and ammeters are no match for experienced professionals.

If you don't have experienced professional testers on your team, you either have developers doing it badly, or worse, your users are doing it for you, which is hurting your reputation. Either way, I worry about the outcome of your project.