I received an email the other day from Giorgio Valoti in Italy, but when I wrote a response, it bounced back with "recipient unknown." It may have been a transient error, but it made me think that others besides Giorgio might be interested in discussing the issue of classifying errors, so I'll put my answer here and hope Giorgio will see it.
Here's the letter:
Dear Mr. Weinberg,
My problem is that I’m looking for good way — maybe a standard, more likely a set of guidelines — to classify and put a some kind of label on software defects.
Is there such a thing? Does it even make sense trying to classify software defects?
And here's my reply:
 |
Hello, Giorgio
It can certainly make sense to classify errors/defects, but there are many ways to classify, depending on what you're trying to accomplish. So, that's where you start, by answering "What's my purpose in classifying?"
For instance, here are a few ways my clients have classified errors, and for what purposes:
- cost to fix: to estimate future costs
- costs to customers: to estimate impact on product sales, or product market penetration
- place of origin in the development cycle: to decide where to concentrate quality efforts
- type of activity that led to the error: to improve the training of developers
- type of activity that led to detecting the error: to improve the training of testers
- number of places that had to be fixed to correct the error: to estimate the quality of the design
- and so on and on
I hope this helps ... and thanks for asking.
--------------end of letter-----------
As the letter says, there are numerous ways to classify errors, so I think my readers would love to read about some other ways from other readers. Care to comment?