How many testers does it take to test a product? This sounds like the opening to a water cooler joke, but it’s a serious question. Quality assurance is an important function, especially in today’s “release early, release often” world.
Some folks try to answer this question with the elusive developer-to-tester ratio. Can you figure out how many testers you need by looking at the size of your development staff? Should you? Or is there a better way to size your testing team and make it more efficient at the same time?
Why use a Developer-To-Tester Ratio?
Basing your testing staff needs on how many developers you have seems to make sense for a “rule of thumb” estimation. The amount of code produced by your staff and the rate at which they release it substantially impact your testing needs.
So, one approach might be to look at how frequently your developers release code and how long it takes to test each unit. From there, you can extrapolate what your testing queue looks like. Let’s assume you have ten developers. Say they release every four days and that the code needs a day’s worth of testing. This works out to a little more than one tester for every two developers.
This is, of course, still very much a rule of thumb. Not all developers are created equal, nor are all testers. More importantly, not every feature or bug is created equal, either. You can test some releases in a few hours. Others may take as long as a week.
So, How Many Testers Do I Need?
Is there an ideal developer-to-tester ratio? One tester for every three developers? One for every four? Maybe you can’t afford to have any bugs in your product, and you’ll go first class: one tester for every developer! This may sound outlandish, but according to the book Microsoft Secrets, that’s the ratio that the company uses.
But there’s no ideal ratio. Throwing the workforce at testing isn’t guaranteed to avoid problems. Too many testers can lead to conflicts or underutilized resources. Hire too many testers, and you may have created the next round of layoffs.
What Are Your Testing Scenarios?
Your testing scenarios play a larger role in your testing needs than your development staffing levels. Do you have a large number of scenarios? How long does it take to perform them? Does your staff run them frequently?
These questions do still allude to the rule of thumb above. While the number of developers might not drive your testing needs, their release schedule will.
Your testing staff should have full regression test procedures and quick checks they use for quick fixes. You can’t predict all of these scenarios. The best you can do is an estimate based on experience. How often do your releases call for these different scenarios? Hopefully, what’s past is prologue, and you can make accurate predictions.
Variety of Products and Platforms
We’re getting closer to an effective way to predict how many testing staff you need. Rather than looking at the number of developers you have, look at your product. How many different products or variations do your developers produce?
Are you lucky enough to have an internal product that runs in a tightly controlled environment? Then your testing needs are probably relatively modest. You can get by with fewer testers.
Are you running a website that has to support a broad feature set on a wide variety of browsers? If that’s the case, even a small fix could trigger a full regression across several platforms.
Don’t forget the back end of that website. It may resemble that simpler internal product above, but it still has to be accounted for.
Do you support a product that’s deployed to client sites on a wide variety of platforms or a broad range of environments? It would help if you had testing that’s deep and wide. It would be best if you had a full staff, and they need to be deeply involved with your process.
What’s Your Methodology?
Are you using agile methodology? If you are, your testers play a larger role in the development process than if you’re not. Your testers are part of agile teams that design, build, test, and deploy the product.
Since they’re team members involved in the overall development process, the developer-to-tester ratio is relevant. Whether the teams are permanent or vary from project to project, you need enough testers to build the teams.
If you’re not using agile, building teams might not be a factor, or your teams might be built around products or projects. In this case, you’re back to making estimations based on your development cycle and your product’s complexity.
How Many Testers Can You Afford?
Technologists usually don’t like talking about costs, especially when it comes to staff. Managers are responsible for the well-being of their employees and the business.
Throwing more workers at testing might look like a good idea, but is it a sustainable solution? Will management support it? Will your testing staff be the first people to go when things get tough?
Is There a Better Way?
Yes, there is a better way. Don’t focus on metrics like the developer-to-test ratio. Work on making sure your testing efforts are as efficient as they can be. Focus on test automation. If your testers are more efficient, then you’ll have a better idea of when it’s time to add more.
Is this a way to cut back on staff? No. It’s a way to make your testing staff more productive. It’s a way to make your product more reliable.
We talked about the Seven Essential End-to-End Testing Best Practices a few weeks ago. Take a look at the first one.
If you can automate something and you plan on repeating it, you probably should do it.
If you automate your tests, your staff can focus on making the tests better. They can find edge cases and add them to the test. Instead of rushing to complete the next test cycle, they can work with your development staff at anticipating the testing requirement for the round after that one.
Automation helps you move quickly. We talked about how your development team’s release velocity affects your testing needs. Automating as much of your testing as possible eases this pressure.
Automated tests are faster, which means you can run more tests per iteration and fewer testing errors. So, your test coverage will increase over time while your staff works on adding more features to the next cycle.
Automate Your Tests Quickly
Stop trying to divine the magic developer-to-tester ratio. Make your testing staff more efficient and a lot happier, instead.
Automating your testing process will save you time and lead to a higher quality product. And the good news is it doesn’t have to be hard, either. With Testim fast authoring, you can record a test suite in minutes and repeat it as many times as you need to. You can record multiple tests and factor the common steps together for reuse. Take Testim for a test drive today!
