Looking beyond the Tester-to-Developer Ratio
Most companies I have worked with have some notion of an ideal tester-to-developer ratio, or the number of testers they need for every certain number of developers. One tester to every two developers is one I hear pretty often.
The question always annoys me at a superficial level. It is asking for a blanket solution to a changing problem. But it is rooted in a very real need to understand staffing requirements and budgets. So, how do I approach the ratio?
The first thing I like to do is track cycle time: how long it takes on average for a story to move from in development to in production. This at least will give you some data—sure, it could be gamed and is problematic, but it is also a place to start asking questions. The number one question is, how we can go faster? If you have a bottleneck between when development is done and testing begins, then the first answer might be to add one more tester.
What I would do at this point is take a look at what is happening on the development team. Years ago, I was working on a team of four developers. We routinely got new builds with completely obvious bugs, like easy-to-find array overflows and the page crashing when you submit a form. Every bug we encounter requires more time to research, document, discuss, maybe triage, and then test all over again when it is fixed. Using development practices such as test-driven development is one way to massively cut down on time spent here.
The next question I ask is, how separated are your testers and developers? The time it takes to move to production increases slightly—or not so slightly—every time a piece of work is handed off between roles.
One company I worked with had developers and testers in separate parts of the building. Developers would write code in one large swath until they thought a feature was done, and then that code would be stuck in a queue for a build manager to package and put into a new build. Eventually someone on the test team would have a new build with testable code.
Another company I worked with had developers and testers work together collaboratively until a change was ready to go to production. The developers were able to write code in small pieces that was tested as it was being written. When testable builds were ready, both people discussed what needed to be explored and did the work together. The last testing push, which usually takes a long time, was brief because of all the work done up front.
If you need more testers because your code quality is low or testing skills are monopolized by a small group of people, then solve those problems first. If your developers are test-driving their code and delivering in small batches without handoffs and you still have a throughput problem, maybe it’s time to look at hiring another tester.
