In a book I have, there is a following classification of defect:
- Critical : A defect receives a “critical” severity level if one or more critical
system functionalities are impaired by a defect with is impaired and there
is no workaround. - High: A defect receives a “high” severity level if some fundamental system
functionalities are impaired but a workaround exists. - Medium: A defect receives a “medium” severity level if no critical functionality
is impaired and a workaround exists for the defect. - Low: A defect receives a “low” severity level if the problem involves a
cosmetic feature of the system.
To be honest, I do not get it.. For example point 2. What if fundamental but not critical feature is impaired and there is NOT a workaround. The same for point 3: what if no critical functionality is affected but there is no workaround?
E.g. optional field in the registration form does not work. No workaround but barely an issue.
1
You have a book making suggestions how to categorize issues, and the suggestions leave out some intermediate cases – because your book just tries you to give you a rough guideline how things could be classified, no less, no more. Just like any book, such rules should not stop you from thinking by yourself.
Think about this in context of your specific real-world case (for example, when implementing an issue tracker in an organization, for specific software system) – how do you want the issues to be categorized? Where do you draw the line between “critical” and “fundamental” features in your context (is there even a difference)? Are those 4 categories those you need, do you need more, do you need less? Perhaps your issue tracker allows to enter attributes for both “importance of the feature affected” and “does workaround exist”?
There’s a good metaphor, issue severity scale is relative.
It’s only goal is to provide means for prioritizing bug-fixing effort. The ultimate question is, “what issues to focus on, in the first place?”, and the answer is a sorted list of issues. If the list does not work that way, it becomes useless.
There are many considerations specific to the product you’re working on:
- Workarounds may or may not be relevant at all.
Say, you are developing a firmware for a washing machine, and a certain button does not work as expected – would you even consider if there is a workaround by simultaneous pressing two other buttons? - The definition of “Critical feature” also changes.
Say, you are working on version #15 of your product, and it has planned feature ofA.
According to your plans, there will be another featureBscheduled for version #16.
You find a failure in featureB, and you need assigning severity. Regardless of the factBwill become critical for release #16, it is not that important for current release. So you assign it medium severity so that the developers were not wasting their time now. As soon as release #15 occurs, the severity should be updated.
It is impossible to draw clear lines between these categories. In practice, it doesn’t matter. We assign categories to communicate with the people who will respond to the defects. When a defect is discovered, choose the category that will elicit the response most useful to the enterprise. If it has to be fixed as soon as possible, and preferably sooner, it is definitely critical. If it’s important, but can be managed during normal work hours, maybe it’s high.
Organizations should not create processes where the precise categorization of defects drives financial rewards. That creates incentives to work outside the defect tracking system.