What is the most common labels for the bug severity: High-Med-Low-etc., A-B-C-etc., 1-2-3-etc. or different? Where they origin? What is the best practice to use?
A label is just a label.
It is far more important to understand what stands behind them, so people can easily say when to assign a certain severity to a bug and understand what such severity means in terms of business impact. This is important because depending on the severity* your stakeholders may take appropriate action. E.g. stop releasing the product or postpone fixing the bug.
For instance, we define Sev 1 when whole system is not working because of the bug, and Sev 2 when only one of the important features is broken. We usually do not accept Sev 1 and Sev 2 in the release, while Sev 3 requires further discussion.
*Obviously, this is simplification. Severity alone might not be enough to take an informative decision, so other parts of bug report can help decide.
The ratings that I see in common use and have used historically are:
- Severity 1 - Critical issue, crash or data loss
- Severity 2 - Major issue, but no crash or data loss and no workaround
- Severity 3 - Issue, with no crash or data loss and a workaround exists.
- Severity 4 - Fit an finish issues.
The main decision that needs to occur for each bug is "Are we going to hold the release of the software because of this bug?". If so then it is a Sev 1 or 2, if not then it is a severity 3 or 4.
On really big projects with hundreds or thousands of bugs, you need to add priority as well to allow business stakeholders to choose the fix order. That normally gets a 1-4 rating as well of :
- Priority 1 - Critical, stop everything and fix ASAP.
- Priority 2 - High, fix before the next release into testing.
- Priority 3 - Medium, fix before the release ships.
- Priority 4 - Low, fix if time, but can be moved to the next release.
With this system in place, the severity is a technical impact that is set by the testers and cannot be changed. The priority can change throughout the life of the project, especially for priority 3 bugs when they are getting lowered to priority 4 as the shipping deadline approaches.
This also allows you you decide to ship with crashing bugs, if they occur only in really, really rare circumstances.
I like to use the following:
Visualize each one falling on your head...
The beauty of this system is when you also visualize a truckload of sand being dumped on your head. Even though a system may have no huge issues, too many small issues can make it unusable as well.
My 5 cents
- Blocker: The defect affects critical functionality or critical data. It does not have a workaround. Example: Cannot login, cannot upload data,
- Critical: The defect affects major functionality or major data. It has a workaround but is not obvious and is difficult. Example: All exceptions, security bugs
- Minor: The defect affects minor functionality or non-critical data. It has an easy workaround. Example: Open unexpected page
- Trivial: The defect does not affect functionality or data. It does not even need a workaround. It does not impact productivity or efficiency. It is merely an inconvenience. Example: Petty layout discrepancies, spelling/grammatical errors.
The importance of any label is only as much as you make of it. It's just a label and not a law. There is no specific standard for that.
The most appropriate practice to follow for labeling bug severity is to sit down with your project team and decide?
- what suggestions you have for it?
- Would they like to make any changes to your suggestions?
- Do they have better option/proposal that is acceptable?
And you can do it with anything,
- Alphabets Words
- Color Codes
Or any other thing that you can think of.
Bug severity is only for conveying a message of the importance of how badly a bug can affect the software and that it needs to be fixed immediately or can be dealt with after other priority fixes. This message can only be conveyed most effectively when the team and you use a system that all understand equally.
In my opinion, most common categorization is A-B-C, eventually A-B-C-D. Ideally there should be a description for each severity agreed by all stakeholders. For example it could be like this:
Severity A or 'Critical' : defect that need to be fixed before the application can be released into production. Some part of application is not working at all or it can cause business or financial loss. There is no workaround.
Severity B or 'Major' : defect causes great deviation from the business requirements if released into production. Workaround is possible.
Severity C or 'Medium' : defect causes minimal deviation from the business requirements if released into production.
Severity D or 'Minor' or 'Cosmetic' : defect causes no deviation from the business requirements if released into production. It could be static texts, colors etc.
Additionally, bug can be categorized as a Showstopper. It means tester could not continue in his test. Usually showstopper has severity A but rarely it could be lover severity, depend on the situation.
Why not just two levels: NOW or LATER. NOW means address it now, as in before you go to lunch/go home. LATER means that your boss keeps it on his list, until too many things become LATER, and then it effectively becomes somebody else's problem, since it will take another "discovery" to reintroduce the bug/inconvenience to the "NOW or LATER" decision.
If something is annoying or inconvenient, but assigned the LATER label, it will not cause a problem by itself, but enough of these and somebody will force part of the collection into NOW.