How many testers does it take to change a light bulb?

  September 07, 2005

Q: How many testers does it take to change a light bulb?
A: None, we just test for darkness and log the result. Fixing it is someone else's problem.

The question of how many testers a company should hire per developer comes up all the time. It's an important ratio to get right - too few testers and your entire quality process is understaffed: You're less likely to find critical issues before release, and you'll rarely get an accurate insight into the state of your projects. If you hire too many testers, your company will waste money, and extra testers running loose without enough work is not a pretty sight.

It's a difficult question without an easy answer, there are so many variables to consider:

  • How complex is the project?
  • What is the size of the customer base?
  • How skilled and experienced are the programmers?
  • What kind of development process is in place?
  • How experienced are the testers?
  • How productive are the programmers?
  • Does the organization have a culture of quality?
  • What platforms are supported?
  • How many technologies are being integrated?
  • What kind of bureaucracy and politics exist in the organization?

Setting hiring quotas based on a number like tester to developer ratio is pure speculation, but conventional research suggests the most common ratios are from 1:1 to 1:3 testers/developers, and then adjust depending on the specifics outlined above. At AutomatedQA, we have a rough ratio of about 1 tester to every 2 developers, but the actual number varies by project and development stage. For example, TestComplete requires more testing than other projects so the ratio is usually higher, especially in the weeks before a major release.

What if you have a one developer shop? Your best bet is probably to divide the day or week into segments based on your multiple roles, developer, tester, and documentator. (We'll leave sales, marketing, administration and janitorial for another article.)  You could develop for 4 hours, then test and log issues for 2-3 hours, and finally write the documentation for another hour. It's not as romantic as a 3 straight days, no-sleep, all coding marathon, but even as a lone developer you shouldn't shy away from ensuring the quality of your products.

For more details and insight, check out this article Managing the Proportion of Tester to (Other) Developers" by Cem Kaner, 2001. Notice that Mr. Kaner indirectly refers to testers as developers. I wonder what he'd have to say about that light bulb joke?