Are there any substantiated recommendations how many testers a team should have per programmer? I'm more interested in opinions referring to an old-school development approach (no agile stuff) and larger projects. Sources are welcome.

  • 2
    "an old-school development approach" do you mean Waterfall methodology?
    – StuperUser
    Jan 5, 2012 at 16:11
  • 3
    Please don't ask for opinions - that leads to discussion which is not what Stack Exchange does well. Instead ask for proper documented research.
    – ChrisF
    Jan 5, 2012 at 16:11
  • 5
    In Agile projects I have been in the average was 3:1. In every Waterfall project I have been it was probably 2:4:1:10, (2 Project Managers to 4 Business Analysts who never get held accountable for incomplete requirements to 1 stressed out overworked Developer who never stays at the company for longer than a year to 10 whiny completely untechnical manual testers that constantly bombard the developers with inane questions)
    – maple_shaft
    Jan 5, 2012 at 16:16
  • 3
    @maple_shaft, so a team of 10 developers would have 20 project managers and 100 testers?
    – Malfist
    Jan 5, 2012 at 16:37
  • 2
    I guess it depends on what you mean by testers. GMail was in beta for a long time, and, therefore, has had a ratio of tester:programmer in the millions. Jan 5, 2012 at 17:19

2 Answers 2


From Software Estimation by Steve McConnell (ch. 21.1, p. 237-238):

  • Common business systems (internal intranet, management information system etc.) - 3:1 to 20:1 (often no test specialists at all)
  • Common commercial systems (public internet, shrink wrap etc.) - 1:1 to 5:1
  • Scientific and engineering projects - 5:1 to 20:1 (often no test specialists at all)
  • Common systems projects - 1:1 to 5:1
  • Safety critical systems - 5:1 to 1:2
  • Microsoft Windows 2000 - 1:2
  • NASA Space Shuttle Flight Control Software - 1:10

The data in here is based on observations of organizations that my company and I have worked with in the past 10 years.

As you can see from the data, ratios vary significantly even within specific kinds of software. This is appropriate, because the ratio that will work the best for a specific company or specific project will depend on the developmental style of the project, the complexity of the software being tested, the ratio of legacy code to new code, the skill of the testers compared to the skill of developers, the degree of test automation, and numerous other factors.

  • +1 Just to clarify. These are observations of typical ratios, rather than recommendations of optimum ratios that have somehow been measured to be effective?
    – MarkJ
    Sep 28, 2012 at 11:54
  • @MarkJ, yes, these are observations. And from the explanation quoted, I understand that general recommendations would not make much sense, as the ratio varies significantly even between projects of the same type. There is just too much difference between companies, teams and projects. Sep 28, 2012 at 12:26

My opinion would be that it depends very much on the nature of the project, because some projects lend themselves to more automated testing. For example, a hosted accounting package does not need to content with large number of environments, and the types of tests that need to happen are complicated scripts involving scenarios provided by the business side.

On the other hand, if you're developing an Android app, you'll probably want people to physically test on a wide variety of common phones, which isn't easy to automate.

I've worked at two places that I felt got tester ratio right. My current company has no testers -- everything is an automated test, JUnit, RSpec, Selenium or Capybara. This works for our processes and culture.

A previous company had about 1 tester per maybe 4 engineers writing code. This worked well because scheduling worked out so that some of the tests would float between projects depending on what part of the cycle they were on and we'd end up with 1 per 2-3 coders while stabilizing the code.

Some of the QA was in India which was also nice. We'd finish doing stuff at the end of the day, and when we come in the next day, we'd have new feedback from QA.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.