Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.

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?

share|improve this question
    
Good question, I was just about to ask the same! –  stuartf Jun 8 '11 at 11:53
add comment

6 Answers

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.

share|improve this answer
    
A great answer, especially the part about the developer collaboration. –  Todd Bumbarger May 10 '11 at 21:13
add comment

I don't believe there is a 'right' ratio. Factors I would consider requiring a closer ratio:

  • Experience of the QA person with this particular module since newcomers will need a learning curve
  • Experience of the developer with both coding and the particular module (as I have had more than once to have to explain functionality to a developer)
  • The scope of the feature being added since complex features need more time (hopefully they are done early to accommodate to allow for more time to test)
  • Time to production (do I need to "borrow" testers from another dept or team during a crunch time, or is there very little pressure? ha ha)
  • Are the developers running any unit testing or doing any peer reviewing? (Pretty please)
  • What other deliverables are due in this time frame? Service pack releases, etc.
  • How much risk is the company willing to take if the ratio is way off target from where it should be? (push back the date? lessen complexity? bring in more troops? etc)
share|improve this answer
    
+1 for noting that QA is part of a risk/reward decision. Where it is appropriate or acceptable to have a higher risk of defects, less QA may be OK; conversely, if that risk is not acceptable, it will move you toward a lower ratio of dev:qa. –  TomG Nov 14 '11 at 14:22
add comment

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.

share|improve this answer
add comment

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?

  • For some companies, they may take 1 day of casual testing.
  • For other companies, they may take 6 months (perhaps they are in a regulated industry, and the cost of missing a bug is very high)

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?

  • In some shops, a Junior QAer might spend an hour or less checking it out.
  • In other shops, since the new company logo is embedded in the graphic, and it must precisely match the new size and color specifications now required by Marketing, it might take longer.

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?

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.

share|improve this answer
add comment

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

  • Experience of Test Team, Can the team members operate indendently or it is has less experienced testers
  • Type of Testing Done (white box/black box). Depending on it we can arrive at test scenarios
  • If test criteria is 100% code coverage, we need to look at writing an automation suite to arrive at it
  • If test criteria is 100% P1 cases, this is related to identify and executing scenarios
  • Percentage of automation and non automation tasks for every test project. There might be aspects of testing which are not automated (Frequently changing features, newly added feature-pending automation, few browsers left out in automation)
  • Complexity of release, How features are related. If ten unrelated features are released there is no point in assigning it to one person. If features are related then it makes sense to club them and test it together

Looking at the execution model and having data for above parameters would help us arrive at a recommendation for dev-test ratio

share|improve this answer
    
What are P1 cases? –  dzieciou Nov 22 '12 at 21:28
    
Priority One Cases (High priority Cases) –  Siva Dec 5 '12 at 13:51
add comment

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.

share|improve this answer
    
Do they? Legacy systems tend to grow and sprawl, meaning a small change makes really big impacts that you don't expect, many of which go unnoticed without adequate testing. –  corsiKa Jul 11 '11 at 20:41
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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