vote up 1 vote down
star

OK, first things first here:

I know this is, in the words of Michael Bolton, a "unicorn question" and also that the challenge in providing a meaningful answer to this question is compounded because, e.g., the definitions of "what is a 'Systems Test'?" will vary significantly between companies, the cost of fixing defects in production will vary tremendously based on whether the application is web-based or not, etc. Even so, I am interested in: what rules of thumb do you use?

My rationale for asking the question: it is a practical question that managers should think through in order to make useful decisions about, e.g., "how much of our testing effort (and budget) should be focused on finding defects earlier as opposed to later?" "When should we stop testing?" etc.

  • Quick, high-level "gut-feel" rules of thumb would be interesting as data points.

  • Answers that dodge providing specific figures but instead say, "I've addressed the rationale behind the question a few times in different contexts and have found the following ways of thinking about the topics are useful..." would be welcome.

  • Ratios (as opposed to dollar figures) would be totally fine.

  • Different definitions of different phases of testing would be totally fine.

  • Answers citing actual case studies and/or methods used to gather the data would be especially interesting.

  • Answers referring to factors that impact the costs and/or ratios would be superb and "above and beyond" the call of duty. For a great example of how this was done, please see how Cem Kaner et al answered another unicorn question (scroll down to see Michael Bolton's answer).

Thanks in advance.

Justin

flag

5 Answers

vote up 3 vote down

Actually, this is not really a 'unicorn question,' and there has been much research done on this.

Boehm, Barry W. and Philip N. Papaccio. 'Understanding and Controlling Software Costs,' IEEE Transactions on Software Engineering, v. 14, no. 10, October 1988, pp. 1462-1477

Beohm, Barry and Victor R. Basili. 'Software Defect Reduction Top 10 List,' Computer, v. 34, no. 1, January 2001, pp 135-137.

If a company decides to fix a problem in 'production' that could have been found in unit testing the costs are generally significant.

For example, we know how much it costs us on average to release a hotfix to correct a functional issue in a released product like Windows or Office. So, if we could have found that same problem via unit testing the costs would be much less in terms of # of resources, time, forking / syncing code bases, releasing, customer support, etc. Not to mention lost sales, or degraged customer satisifaction as a costs.

Actual costs will of course differ on product type, product distribution, size of customer base, etc. and ratios will differ.

link|flag
vote up 2 vote down

The Boehm writings that BJ recommends are good reads. They're informative w/o being too dense, IMO. I read them when I needed to have metrics to give to my bosses at a big-five consultancy.

(this would have been a comment but I don't have enought rep, apparently)

link|flag
voting you up to give you some rep (so you can leave comments) :} – Alan Jan 28 at 4:27
vote up 1 vote down

I agree, it's a real question that occurs. I have a very instinctive/gut/intuitive feeling about a comparison of the costs here.

The further the bug gets from the developer the higher the potential cost.

"Further away" means post-design-test (unit test), post other testing within the development team (whether that's functional or system test in nature), post-own-organisation testing (more pre-release testing), on-site customer testing followed by customer usage and ramp-up.

A quick list of costs further from the developer that springs to mind is:

  • The developer may be working on something else (there is a start-up cost to get back uop to speed with the affected piece of code plus any context-switching costs, which may have a knock-on affect to the ongoing new development)
  • The original developer may not be available
  • Bugs found under load/stress/performance testing may have architectural impacts (ie re-design needed or limitations on performance/use is advised)
  • Bugs found after "system testing" may need more pre-processing due to the format of the bug report, or information available may be inadequate (request for more info)
  • Bugs may not be locally reproducible for regression testing - additional lab costs
link|flag
vote up 1 vote down

Good chart and good blog post at:

http://www.superwebdeveloper.com/2009/11/25/the-incredible-rate-of-diminishing-returns-of-fixing-software-bugs/

It is also an interesting read as a "developer-centric" viewpoint on relative costs of bug fixing at different phases.

alt text

link|flag
vote up 0 vote down

Yes, I just sent that to a Developer friend who asked me this question earlier and he needed to make a case to a VP who couldn't grasp the concept.

link|flag

Your Answer

Get an OpenID
or

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