I've worked in a variety of environments with differing ratios of QA / SDET personnel vs. developers focused on building and maintaining application features.
Is there such a thing as a "right" ratio? My suspicion is that things vary a lot, but what factors should be considered for the number of staff?
No - there is no "right" ratio. The answer depends on the product (is it a web service providing junior hockey scores, or a space ship?), and the roles that programmers and testers play on the team. I've seen highly successful teams with a 15 or 20 to 1 programmer to tester ratio, and teams with a 1 to 1 ratio that made crap software.
In the high ratio example above, programmers wrote unit tests, functional tests, and worked with testers on acceptance tests, integration tests, and many levels of reliability, performance, and scale tests.
In the 1:1 example I'm thinking of, the programmers would give their code to the test team as soon as it compiled and deal with a huge amount of back and forth as quality was slowly beaten into the program.
Now, of course, you can make great software with a 1:1 ratio, and crummy software with a 10:1 ratio - what's important is that you figure out who does what in the pursuit of quality and that everyone knows what their role is in the effort.
I don't believe there is a 'right' ratio. Factors I would consider requiring a closer ratio:
There is no answer that is "right".
As much as I would love to say that the main influencing factor for most companies is the target quality of the application, however that is not my experience.
The single biggest factor I have seen over the years is that defines the ratio is available budget that the company is willing to spend, and a lot of companies value lower costs over quality.
I can give you some real numbers from my past projects for reference.
For me the highest I have ever seen in Australia is probably 1:3 (so one test per three developers), with 1:5 or higher (less testers) more commonplace. The types of applicaions being developed are large, corporate level commonly internal web based applications.
I think when you get to commercial software, then the ratios need to go up, as the number of tesitng configurations increases.
For example, If I am testing an internal only applicaiton I will typically only need to test on one browser. For a public, internet deployed site, you need to test many, many more.
If you are testing software on the iPhone and you need to target all devices ever shipped including iPod touches there is now something like 12 hardware devices, with three 4 major OS versions.
With that in mind, I tend to focus on delivering as much "bang for buck" from the available headcount that I have.
One of the biggest ways I have seen to tilt the scales in your favour is an effective test automation suite. The reason that is a big factor is that it can essentially "free up" your testers from manual regression to be more effective elsewhere.
If you are trying to justify a larger staff, I would recommend to use metrics to support your case that you need a higher ratio, then capture the results for future reference and justificaiton to your peers.
While Dev-to-Test Ratio is an appealing concept due to its simplicity, it's a poor way to determine the size of your testing staff.
There's no inherent preset relationship between development time and testing time. And there's no inherent preset relationship between development/test staff ratio, and development/test time ratio.
CASE 1
Suppose you had this new requirement:
Your product, which was never previously tested on Windows XP SP2, now must support that OS version.
Development takes 1 day (Windows XP SP1 worked fine, they had to change some text in the "System Requirements" doc, but don't believe they have to do anything else)
Can you predict how long testing should take?
CASE 2
Suppose the company wanted to change their About box.
Replace the former text-only dialog, with a beautiful graphic.
Since the developers aren't very good graphic artists, it takes them 3 days to learn the new graphics tool, 3 days of trial-and-error with the Marketing Department to make it look "just right", and 2 days to get it integrated into the build.
Can you predict how long it might take to test?
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:
http://strazzere.blogspot.com/2010/04/what-is-correct-ratio-of-development.html
To determine the proper staffing model, you must decide what your QA/Test staff will be expected to do and what they will not be expected to do. You must determine what kind of schedule they will operate under. You must determine what level of expertise (both technical and domain expertise) they will need to have. You must determine what amount of outside help they will get.
In short, think about what are the expectations of QA/Test, then let that guide your staffing decision, rather than blindly following a ratio.
Interesting question. I always had this question on how companies arrive at a proposition 1 Test: X Devs
Proposition can be derived based on QA Process, SDLC Process, Complexity of product. From my perspective we need to consider below aspects
Looking at the execution model and having data for above parameters would help us arrive at a recommendation for dev-test ratio
Yes, there is a 'right' ratio:
Factors I would consider:
Another factor to consider is in what stage the project is. Legacy projects, where only bug fixes or relatively new small features are being added, requires less testers.
