Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

At my current job we have Low, Medium, High priority bugs.

  • Low priority bugs are small errors that don't stop shipping or cause real trouble for any user.
  • Medium priority bugs cause some internal users trouble but have known workarounds.
  • High priority bugs are problems that our customers will see, can corrupt data, or crash a system.

How to classify bug severity to complement our priority classification?

share|improve this question
11  
Why do you have impossible-to-understand names like "low", "medium" and "high"? Why don't use just use real words like "crash", "corruption", "known workaround", and "annoyance"? – S.Lott Mar 11 '11 at 14:50
    
Because I have nothing to do with the naming of the priority levels. I just get to use what is given to me. I do like your names for them though. – Erin Mar 11 '11 at 14:52
2  
We have a 4th level, "Critical". It's the worse of the one's you'd classify as "high" (eg. sudden production server failure). – FrustratedWithFormsDesigner Mar 11 '11 at 14:55
1  
I find Low is never used... everyone says its Medium, High, or Urgent – Rachel Mar 11 '11 at 15:18
1  
@Thorbjørn When an error takes more time to put under tracking than to just fix right there when I noticed it, I tend to just fix it. (Mind you, we don't have a formal QA process, so no one else's job is to put bugs in the tracker. It's more of a "to do later" list for us than a work queue from someone else.) – CodexArcanum Mar 11 '11 at 15:43
up vote 21 down vote accepted

We classify our bugs and defects according to both their priority and severity.

The priority level is an indication as to how urgent it is to fix/correct the problem (urgent, high, medium, low, none).

The severity level, helps us identify how much or what kind of damage can be caused by the defect (dangerous/destructive, degraded and no workaround, affected but workaround exists, nuisance/cosmetic, no impact).

Typically, the more dangerous and destructive the bug is, the higher the priority. However, it is not guaranteed. Consequently we can wind up with the occasional bug listed as dangerous and destructive, but due to the rarity of the situation, or the amount of change that may be required to fix it, its priority can in theory become quite low.

share|improve this answer

Severity is really subjective to the kind of product you make and your buisiness. At my last job we made autopilots for large container/cruise ships, so our severity was

  • Very High -- Iceberg Ahead! Oh wait, looks like control of the ship may be lost or it may be confusing who has control! Someone figure out how to turn this ship around!!!
  • High -- Customer acceptance complaints, the cruise ship turns too fast, customers spill their drinks. We can't use your stuff till this is fixed!
  • Medium -- Functionality that would improve the ease of use for customers/field technicians. Stuff that saves people time.
  • Low -- cosmetic things

I imagine the levels of severity/priority will be drastically different if you're making a web app and you have a completely different buisiness model/customer base. Its ultimately about what your customers expect and how angry they get about the issue :)

share|improve this answer
    
+1 for the great descriptions! – FrustratedWithFormsDesigner Mar 11 '11 at 14:56
    
You should overthink your classification of cosmetic things. Cosmetic bugs demonstrate that you don't care. If you don't care then worse bugs are not attributed to bad luck and forgiven but attributed to carelessness. – gnasher729 Dec 2 '15 at 21:59
    
@gnasher729: What's your specific disagreement? Are you saying that a cosmetic bug that doesn't significantly affect how much time a customer spends getting the software to work should be classified as more important than a bug that does affect that and isn't cosmetic? Or what? Priorities are relative, not absolute, and there's always more to do. – Nathan Tuggy Dec 2 '15 at 23:29

Severity criteria that I use:

  • Does it prevent user from getting what he wants from program?
  • Is it visible if user performs typical tasks?
  • Does it reveal sensible information or allow to perform unauthorized actions?

Severity of a particular bug is a combination of these points.

share|improve this answer
1  
Also important is the number of impacted users. And which users, if you're application has features that are not available to all. – FrustratedWithFormsDesigner Mar 11 '11 at 15:01

Classify bugs by their annoyance factor, which can stop people from buying the software. A bug that doesn't affect shipping or causes real trouble to users may be annoying the **** out of me every time I run into the bug. And eventually you lost a user and part of your income.

Now if you combine that kind of bug with a user interface that has been changed for no apparent reason and with no visible benefit for the user, then you have an absolute winner that will make people hate your software.

Don't allow that to happen. Don't ship with bugs that make customers think that you don't give a ****.

share|improve this answer
    
this doesn't even attempt to answer the question asked, "How to classify bug severity to complement our priority classification?" See How to Answer – gnat Dec 4 '15 at 7:07

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.