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.
From Software Estimation by Steve McConnell (ch. 21.1, p. 237-238):
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.