14

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?

Improve this question
7
  • 13
    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, 2011 at 14:50
  • 1
    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, 2011 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, 2011 at 14:55
  • 1
    I find Low is never used... everyone says its Medium, High, or Urgent
    – Rachel
    Mar 11, 2011 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, 2011 at 15:43

4 Answers 4

Reset to default
23

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.

Improve this answer
10

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 :)

Improve this answer
2
  • 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, 2015 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, 2015 at 23:29
0

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.

Improve this answer
1
  • 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, 2011 at 15:01
-1

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 ****.

Improve this answer
1
  • 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, 2015 at 7:07

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