I have just been prompted (via some AdWords) to write a quick blog post around the subject of defect prevention. Not detection, prevention.
For a long time the software testing community has been taught that unless a defect is being managed in a defect management tool, then whatever testing process you are following is probably not fit for purpose. That is, you cant be doing serious software testing, because you are not being serious about your bugs. But it that true?…
No, its is the peddlers of these tools who tell us this.
The software vendors make many fantastic claims in fact
Ergo If you haven’t spent some serious cash on a defect management system you aren’t really testing software, you’re just mucking about. Its crucial to have defect management.
Even HP Quality Center would have us believe that if we use their tool, we will see a “50% reduction in the cost and effort associated with fixing defects”, that is quite a claim.
Interestingly Wikipedia says this “
…Defect tracking is important in software engineering as complex software systems typically have tens or hundreds or thousands of defects
”, holy cow!
Tens or hundreds or thousands? We obviously need a complicated and expensive system to manage that then!
There is of course quite a bit of a difference between having say 20 defects and having 8,000 defects. If I had collected, triaged and managed 8,000 defects, I would expect to get my ass fired, marched right out of the office door. Why? Well for one thing, 8,000 defects is a very good indication that the quality of the product is terrible, therefore something in the build process is very broken, and for another thing, why would you let the number of defects build up to an unmanageable figure like 8,000??
The business can’t make any money out of those defects, it can’t market them, so why invest in them? Why give them a home? Why give them so much time? Managing defects requires a lot of time.
Let’s say it takes 3 minutes to raise a defect, a further 3 minutes for it to be triaged and accepted as a defect, a further 5 minutes for the developers to decide if they accept it (can’t fix/won’t fix), then say a daily defect meeting to update status etc, that takes about 3 minutes a defect (I’m being very optimistic), then a weekly project meeting where the defect list is discussed again.
That’s about 15 minutes of pure ticket pushing for a defect, and that’s before it gets bounced around several times as “can’t reproduce” etc.
So for 8,000 defects that equates to some 234 working days. You haven’t even fixed anything yet, that’s just pure defect management overhead. You think I’m over egging the pudding? Then go tell your CFO, and see what they say.
However you slice it, it is waste.
So, take a long hard look at your defect tracking tool, and ask yourself, is there another, less wasteful way?
The answer is yes. Defect prevention.