How many developers does it take to test a product?

Most development shops want QA testers involved in creating their new software. But what’s the proper ratio of testers to developers? Yes, “it depends,” but let’s look at the answers to, “…on what?”

Development shops generally agree that quality assurance testing is a good thing, but that attitude is by no means universal. Even when development teams want QA testing, they may disagree about how many team members should devote themselves to testing full time rather than writing code. In a few organizations, the policy seems to be that developers should do their own testing, eliminating any need for separate testers.

Adding to the lack of agreement is the fact that not all types of development are the same. For example, teams developing interactive, informational webpages require different testing procedures than do teams creating airliner control systems. Likewise, some approaches, such as Agile development, have a built-in tester-to-developer ratio in which QA testers are an essential part of the team. 

Still, in general there must be an ideal ratio of testers to developers, right? Well, maybe. As with everything else, the most you can say is that “it depends.” There are lots of reasons to say, “It’s time to hire a new QA professional,” after all. 

So if you realistically need a QA team, how big should it be?

Start with one tester for two-to-five developers, and adjust accordingly

Again and again, I was told about that popular ratio: one tester for every three to four developers. But use that as a starting point, not a formal design pattern, urge experienced developers and testers.

“There is no set-in-stone ratio that works perfectly for every scenario,” said James Boatwright, CEO of Code Galaxy, which teaches programming skills to children. The testing scenarios should guide you. “While in most cases, for every two to five developers, one tester would be fine, some circumstances may require one tester for every developer, or maybe even two developers,” he says. This allows testers to focus on specific platforms or use cases. 

As Jimmy Kamboj, founder of custom software firm Imenso Software, says, many variables come into play, ranging from the availability of automation tools in testing to the income reliability of the project, to how much of the testing can be automated. “While one good tester is enough for a set of three, perhaps even four developers, a lot of things – like what is the scale of the project and what is being built – is extremely crucial to determine the ideal ratio,” he explains. 

If your project uses Agile methodology, expect to hire more testers, because its premise includes the expectation that the testers are actively involved in improving the product.  At custom web development company Sprout, squads have four developers, one user interface/user experience specialist, one product person, and one QA tester, says the company’s director, Arnold Sebastian Egg. After a sprint is complete, an automated QA engineer automates the previous test scripts of the previous test journey to make sure quality is maintained, Egg adds. 

While a 3:1 ratio is the popular answer, it’s certainly not the only answer. For Reuben Yonatan, founder and CEO of GetVoIP, development team size is usually five or six developers. “An average team will therefore have two testers and five developers to make a total of seven. I am comfortable with that ratio, and from experience, more developers might hinder the product instead of enhancing it.”

Adjust developer:tester ratio based on expertise requirements – and tester experience

Complex projects require more people to connect the dots, or specialists who know how to find bugs in particular knowledge domains (such as security testing or mobile applications). That may justify hiring someone with particular knowledge. That boosts the “standard” ratio to one QA tester for every two developers.

“The more complex a project, the more developers and testers it requires,” says Michal Kowalkowski, co-founder and CEO of NoSpoilers.AI, where the developer:tester ratio is currently 3:1. “But writing tests can prove slower than the actual development.” 

“Some features we develop take less time to test and troubleshoot, but some features are really complex,” agrees Oleg Donets, CEO at ODMsoft, which currently employs seven developers and two testers. “If we decide to get more developers on board, we’d try to keep the QA people in the same ratio.” 

The ratio of two developers to one tester is used by Daniel Florido, lead developer at web development firm Pixelstorm. “Testers are not just responsible for testing software end output. All development tasks should be tested, for technical bugs, device, and browser bugs as well as functional testing and usability testing.” That also enables developers and testers to learn one another’s style and practices. Testers may learn about a developer’s the strengths and weaknesses, and find out how to best provide feedback. Doing so, explains Florido, improves efficiency as well as team morale. 

“We've spent years working out the right ratio for both profitability and accurate product delivery,” Florido continues. “For a tester to do what they need to with complete focus, this is the ideal outcome.”

Look at other ratios, too

But you should look at more than the number comparison for “developer head count.” Jon Quigley, principal of Value Transformation, allocates testers in a development environment based on financial number. “It should be 30% to 50% of the hours or money. For every two people that’s one tester or testing activity.”

Depending on project size, that testing activity could involve a lot of people. Quigley’s specialty is mission critical applications, including automotive, heavy truck, and mining equipment product development. A single failure could lead to death or disaster.

Can you afford to hire another tester? Can you afford not to?

Whatever your team’s need for QA testing, and its ability to hire good people, the need for QA testers can only grow. David Moise, president of Decide Consulting, says that this could be a challenge. “There is a 9:1 ratio of developers to testers in the job market,” Moise says, noting that this has improved from an earlier ratio of 11:1. “To include front end people, it’s more like 13:1.”

That means it’s harder to hire QA testers that it used to be. “The skills are changing and there are more demands on what people need to have,” Moise says. “Before, you needed just to have experience testing. Now you need experience using automated platforms. They’re more expensive.” 

What this means to the tester-to-developer ratio: It’s going to cost companies more to hire the testing staff they need. (On the other hand, if you’re a tester looking for a new job, this means you can ask for more money! Yay you! Just be sure to level-up your QA tester’s resume.) 

And before you can accomplish that, you need buy-in from the people who hold the purse strings – who think that the developers can do it all. According to Sami Ullah, spokesperson for Kulitatem, a software QA testing company, some companies simply don’t want to spend the money. “They think QA as overhead for the company,” Ullah explains. That might happen, he posits, when “the company is quite small so they can’t afford hiring separate QA staff; the company has not defined departments and roles; they don’t realize the importance of QA (which they will eventually realize, after rolling out buggy applications in production).” 

“Management has to see the value in QA,” Moise says. The considerations need to include the cost to fix a bug versus finding in during development. The amount of risk are you willing to tolerate, and the potential damage to your product’s reputation if your software looks bad. “Some companies don’t get it,” he says.

Who does that hiring? Who makes this decision? As our white paper argues, perhaps it should be the chief quality officer.

‍

by Wayne Rash

Wayne Rash is based in Washington and has been writing about science and technology for nearly 40 years. He is a contributor to Forbes.com and a columnist for eWEEK. He is a frequent speaker on technology and has been a guest on NPR, NBC, PBS, CNN and Fox News.