Skip navigation.

Effort distribution - QA/Test to Development

test management

I noticed that someone was searching for information on the distirbution of effort in terms of "numbers of Developers to QA/Testers"... I don't like referring to testing as "QA" (because it isn't QA per-se - but that will be the subject of a different blog)... anyway, I thought I would put my perspective here anyway...

FAQs.org has some information on ratios in this post. A key point made here is...

Boris Beizer adds:

These figures can all vary very widely depending on how you define "tester" and "developer". In some organizations, a "tester" is anyone who happens to be testing software at the time -- such as their own. In other organizations, a "tester" is only a member of an independent test group.

It is far, far, better to ask about the test labor content than it is to ask about the tester/developer ratio. The test labor content, across most applications is generally accepted as 50%, when people do honest accounting. For life-critical software, this can go up to 80%.

This is now especially true of test-driven development where developers are also spending 30%-50% of their time just on testing! Large-scale applications that must be secure and 'performant' add additional demands as non-functional testing in itself soaks up even more of the project-effort.

Bret Pettichord's Testing Hotlist points you at this article

This interesting presentation from rtpspin.org has some very useful statistics if you are looking for some good sound-bites.

**Developer : Tester Ratios Theories **

SQA 'theory' generally recommends:

      3:1 at most when:

      Very mature processes

      Accurate, clear documentation

      Non-configurable application

      1:1 or less when:

      Little or no process

      Documentation unclear / out of date

      Highly configurable application



These are generalizations at best but
are useful for comparison purposes
 
*Developer : Tester Ratios An Informal Study **

29 companies responded

Maximum ratio: 1 developer to 0 testers

Minimum ratio: 30 developers to 1 tester

Most common ratio: 3 developers to 1 tester

Average ratio: 7 developers to 1 tester

Median ratio: 5 developers to 1 tester 

(Randall W. Rice, “The Elusive Tester to Developer Ratio”)

(Based on an informal study at the 20th annual QAI Software
Testing Conference, September 2000)

So I am wondering... could this have something to do with why 50-80% of software projects still fail?

**Developer : Tester Ratios Some Industry Examples **

Some examples of developer to tester ratios:

      Space shuttle project = 1:3

      Large statistical software company = 1:1

      Huge software conglomerate = 1:1

      Healthcare IT firm = 4:1

      Analytical CRM company = 4:1

      Technology consulting firm = 8:1

  These are based on mostly anecdotal data
  Very few companies will publish this

  Except those who can afford 1:1 ratio

My experience is, you ask for what you need and you get what you are given (budget)... so... during the project...

* Measure the successes/failures of the approach and stay aware of the risks as they reveal themselves.

* Provide this information as informational feedback (not evangelical assertiveness) to the project manager and let them decide how to manage the risks. They will see the light for themselves more quickly by walking their own path. Try to drag them kicking and screaming and they will always be looking in the opposite direction to you.

* While they walk their path, you get to do some interesting and useful testing!

Good luck!

Rule of Thumb: QA Effort

TrackBack from Observations from a Tech Architect: Enterprise Implementation Issues & Solutions:
The percentage of total effort applied to quality assurance activities is from two to ten percent.This rule of thumb provides a reasonableness check of the quality assurance effort, considering the total project effort. Details follow...

Comment viewing options

Select your preferred way to display the comments and click 'Save settings' to activate your changes.