The Ideal Tester-Developer Ratio

People often ask me, “What’s the ideal tester-developer ratio?” My answer is always, “It depends.” There are a number of factors that determine what a good tester-developer ratio should be. Things to consider are: whether you are working on cutting-edge technology or a legacy product, the talent and experience of your team members, and what kind of release cadence you are expected to maintain. The truth is that there are all different kinds of ratios that can work, but there are pros and cons to each. Let’s take a look at some examples.

1 tester: 1 developer

The 1:1 ratio is great when you have developers who don’t know much about testing and testers who don’t know much about development. A developer-tester pair can work together to release a new feature, and because they are both so focused on that one feature, they may be able to find and fix all the bugs. However, the developer probably won’t contribute to any test automation, and the tester will likely be the only one who knows how to run and fix the automation. This will mean that with any future development on the feature, the tester will become a bottleneck, slowing down the work.

1 tester: 2 developers
This ratio is good for a situation where there is a front-end and a back-end developer working on a feature. The tester can be responsible for testing the integration between the front and back ends. Like the 1:1 ratio, these three will become the experts on the feature. However, this can result in silos, where it’s difficult later in the project for someone else to come in and assist with the work.

2 testers: A team of developers
This is a very common scenario. The testers can divide up the stories to test according to their skillset and availability. If both testers are talented and organized, they will usually be able to keep up with the manual testing and the test automation work. They can also swap features to see if one tester has missed a bug that the other finds. However, this ratio will occasionally result in bottlenecks when there’s a feature that needs a lot of testing or if one tester goes on vacation.

1 tester: A team of developers
In this scenario, the tester becomes a “quality coach”. They are not responsible for all of the testing or all of the test automation. They guide and train the developers to understand what should be tested and automated. In this way, the whole team owns quality. Any time the tester is not available, the developers are able to fill in the gaps by creating test plans and testing each other’s work. Because the developers are contributing to and helping to maintain the automated tests, test automation never becomes a bottleneck.

0 testers: A team of developers
Some might cringe in horror at this idea, but a team of very well-trained software developers is capable of doing all their own testing. In order for this to be successful, developers need to understand the importance of exploratory testing and how to create test plans. They need to understand what kinds of tests should be automated, and they should be committed to maintaining their test code as carefully as they maintain their production code. Although they will do some initial testing on their own features, they will also create “test buddy” pairs where one developer will act as the tester for another developer’s work. In this way, they’ll have two sets of eyes on each feature and will be more likely to catch bugs.

These ratios all have a few things in common. First, and most importantly, at least one person on the team has excellent testing skills. Those skills are necessary to find elusive bugs. Next, good communication skills are needed. There is no “throwing software over the wall to be tested”; testers and developers are working together. Finally, there is the willingness to be a team player. Testers and developers alike need to be willing to step forward and do testing tasks whether or not it’s part of their assigned role. When all three things are present on a team, any of these ratios can bring success.