Question

What is a good ratio of QA tester to developer and why?

Answer 1

This is a unicorn question: "What size unicorn do you wear?"

http://www.satisfice.com/blog/archives/67

There is no right answer to this question. See "Managing the proportion of testers to (other) developers", at http://www.kaner.com/pdfs/pnsqc_ratio_of_testers.pdf.

---Michael B.

Answer 2

You want to have exactly enough testers.

Or, a better answer may be "it depends".

The ratio can be influenced by tester experience, developer experience, complexity of the product, life-span of the product (is it version 13?), and many other factors.

If you have too few testers, you risk having nobody think about quality. If you have great developers, you may not need testers (although a few to keep them honest never hurts).

My feeling is that ratios at or nearing 1:1 breeds lazy developers who throw bad code "over the wall" to testers. This isn't always true, but is true often enough to be scared of it.

I have a blog post on this also here.

Answer 3

A couple highlights from the excellent article by Cem Kaner that Michael Bolton referred to in his answer...

ARE LARGER RATIOS BETTER OR WORSE? Most of the participants at STMR 3 (including us) had worked on projects with high ratios of testers to programmers, as many as 5 testers per programmer. Most of us had also worked on projects involving very low ratios, as few as 0-to-7 and 1-to-8. Some of the projects with high ratios had been successful, some not. Some of the projects with low ratios had been successful, some not. This corresponds with what we've been told by other managers, outside of STMR. Why are some projects successful with very few testers while others need so many more?

---

Low Ratios of Testers to Programmers Most testers have seen or worked in a test group that was flooded with work and pushed up against tight deadlines. These groups typically staff projects with relatively few testers per programmer. The work is high stress and the overall product quality will probably be low. However, some projects are correctly staffed with low ratios of testers to programmers. In our experience, these projects generally involved programmers (and managers) who had high quality standards and who didn't rely on the test group to get the product right.
Projects with low ratios of testers to programmers might occur: • routinely, in a company with a healthy culture whose projects normally succeed • routinely, under challenging circumstances • on a project-by-project basis based on special circumstances of that project

---

FACTORS THAT INFLUENCE STAFFING RATIOS AND LEVELS Suppose that your boss calls you into a meeting and says, "We have just been assigned Project Whizbang. It will take 20 programmer-years. They started last week and will be done in 6 months. How many testers do you need?" How do you come up with an answer?

---

The above snippets represent just a teaser of Kaner's excellent 17-page paper available at: http://www.kaner.com/pdfs/pnsqc_ratio_of_testers.pdf.

Answer 4

There's no inherent preset relationship between development/test staff ratio, and development/test time ratio.

http://www.sqablogs.com/jstrazzere/150/What+is+the+%22Correct%22+Ratio+of+Development+Time+to+Test+Time%3F.html

Clearly, the time required to test something is contextual - it depends on factors that may have little or nothing to do with how long it took to develop that feature.

Also consider:

• what counts as Development?
• what counts as Testing?
• If we were going to perform regression testing anyway, does that count as "zero" additional testing hours?

Answer 5

I actually like these types of questions - totally open-ended, no right or wrong answer and as several have mentioned very context specific.

I overheard a discussion today where the test effort (post coding & unit test) for a bug was about 3 times more than the coding & unit test. There was exasperation from certain people on the design side.

To me, that's just an opportunity to step-in and try to enlighten - ensure that people are not getting caught up in the details and think about the big picture... (Actually, I didn't step-in on this particular occasion as they were about to head off to lunch and there's nothing worse than trying to talk to people that are not receptive - ie if they're hungry...)

So, I like these questions - test/dev ratios or test/dev effort. They are the type of questions higher management have - so it's quite reasonable you'll get asked them once in a while.

If you apply them to your own circumstances you'll probably get lots different answers even within the same project. Try and think about the question in one of your own examples - it's a good thinking and learning exercise - especially if you think how you might explain to a PM or other stakeholder.

Answer 6

It is a great question that many organizations struggle with.

I've seen a group of 0 testers and 10 devs put out an amazing product. And a group with more testers than developers get into the weeds with quality issues.

I'd suggest asking more questions:

1) Are the developers throwing poor code over the wall, or blaming testers when bugs are missed? If so, you don't need more testers, you need an attitude adjustment. No matter the ratio, developers need to take pride in their work, care about quality, and feel bad when they make mistakes.

2) What sort of costs are there to mistakes? If you have a reputation to uphold, expense in patching, or loss of lives due to mistakes, you'll spend more on testing.

3) What non-testing work do testers need to do? For regulatory or audited test efforts, there can be a large investment in test collateral and process documents.

4) Is it a very small startup, constrained by money and time to market? Most startups do fine with a handful of developers and no testers. Mid to large size companies start seeing more value in having dedicated testers.

5) How many testers can you afford? If there is budget for 1 more person, can you make a convincing argument to hire another tester and not another developer?

Somewhere around the 1:3 tester:dev ratio, I've seen many teams shift to worse quality, as the developers relax and stop being scared of mistakes.

Answer 7

You also need to know what kind of code you are testing, if its a lightweight application with few moving parts then you need fewer testers than the multi-server installed thick application with a complex UI and data scheme.

This is one of those "it depends" questions, where the answer is not going to be the same for everyone or every project.