Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.

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?

share|improve this question

5 Answers 5

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.

share|improve this answer

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.

share|improve this answer
    
I learned it is important to say what "workaround means". Is it for a end-user (to take another path in UI), or someone who configures the installation (e.g., to manually add missing data) or something else. So what do you mean by a workaround? –  dzieciou Jan 15 at 20:01

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.
share|improve this answer

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.

share|improve this answer
2  
Based on what you concluded A-B-C is the most common categorization? –  dzieciou Jan 15 at 20:02
    
@ dzieciou: based on what it is not? It is not a conclusion, but opinion as everyone is signed. –  Dee Jan 16 at 11:16
    
I updated you answer saying that this is your opinion. –  dzieciou Jan 16 at 12:25

I like to use the following:

  • Boulder
  • Rock
  • Gravel
  • Sand

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.

share|improve this answer
    
funny, but not possible to use in business –  Dee Jan 21 at 20:07
    
Why is it not possible to use in business? –  semaj Jan 22 at 16:10
1  
It communicates the importance of a large number of lower severity issues better that any other posted solution. In fact, none of the other systems communicate this idea at all. –  semaj Jan 22 at 16:17

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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