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

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 do other teams classify bugs in their system?

share|improve this question

closed as primarily opinion-based by MichaelT, Bart van Ingen Schenau, Kilian Foth, GlenH7, gnat Aug 11 '14 at 14:58

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

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
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
I find Low is never used... everyone says its Medium, High, or Urgent – Rachel Mar 11 '11 at 15:18
@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

11 Answers 11

up vote 13 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.

Hope this helps.

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

I prefer MoSCoW: Must, Should, Could and Want (or Wish).

This makes it clear what we must solve before release, what we should solve, etc.

share|improve this answer
I like this approach because it fits in with the idea of a release every X days and what we're going to try to fit in it... very agile – Liath Aug 11 '14 at 10:46

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

For the moment, we're using the default bug classifications that ship with JIRA: blocker, critical, major, minor, trivial (described in more detail here).

I really like the "user pain" scheme of classifying bug severity described in "Improving Bug Triage with User Pain": rate bugs on three simple scales (type, likelihood, and priority), then multiply those values together to prioritize bugs. However, I haven't implemented it myself.

share|improve this answer

I've come across all sorts of schemes because they all depend on the company and industry. When I've worked in the auto industry, we usually use a (company specific) name to match the severity numbers from a FMEA. Generally the lowest levels would be called "cosmetic" while the top 2 levels would be "injures lots or kills one person" and "kills lots of people" respectively.

To your list of "low, medium and high" one could also add "critical" and "catastrophic." Depending on your industry, "critical" might involve loss of money and customers, while "catastrophic" involves breaking regulations and laws that can get you shut down.

share|improve this answer

The Lean alternative is not to classify, but instead decide immediately when a bug is found: solve (and make mistake proof with automated testing like TDD) or accept and close.

share|improve this answer
When you are not allowed to work on some thing unless it is in your list of approved work orders that doesn't work. – Erin Mar 11 '11 at 16:08
@Erin - right. This only works in a Lean environment. But even with a list (to which you are referring, I think) this will work as long as the list is limited to only a few (e.g. 2 or 3) items, known as Kanban: – Wikis Mar 11 '11 at 16:17
Wouldn't that mean you disrupt working on something else? I can't imagine something like that working with any kind of complex task. – Inca Mar 11 '11 at 18:44
@Inca - it depends. You may split your team into two groups - those who work on structural important requirements for the next release, and those (a small group, typcially) who work on lower priority issues and who can indeed drop everything to fix an important defect. – Wikis Mar 11 '11 at 19:50
@Wikis, but isn't that exactly what prioritizing does? Deciding which things can be dropped, and which need immediate attention? Ok, in that scenario you do not classify bugs, but you classify the work someone does, but issues are still classified. – Inca Mar 11 '11 at 19:55

Those you must fix. Those you would like to fix. Those that have nothing to do with functionality and only get fixed if you somehow magically finish every other task and are sitting around and have tired of playing XBox.

share|improve this answer

By the number of users it affects.

"There are no significant bugs in our released software that any significant number of users want fixed." -- Bill Gates

share|improve this answer

Your classification system needs to take into account several factors.


  • Does the bug show up obviously? Does the software report an error to the user or administrator when it happens? Do the logs show clearly what's going on? Even if the bug is an unexpected corner case, if you show an error to the user "dividing by zero isn't allowed" then you have averted the error cascading into future problems and creating a snowball of damage.
  • On the other hand, the bug may not trigger any error reports, not leav an obvious trace in the logs, not be detected until long after it does the damage. You could ship a thousand units to the wrong address and not know it until weeks later when your customers call you up complaining about where's their stuff.

Show Stopper:

  • In the theatre "the show must go on". Unless the stage is on fire, in which case you have to evacuate the theatre and give the audience their money back. Hence the term. You have to shut down the system because it won't work until you fix it.

Data corruption, damage, injury, death

  • Most bugs cause something to not happen. Some bugs cause bad things to happen. Maybe it overwrites records in your database, causing data loss, forcing you to go to backups.
  • Maybe it causes damage to some kind of physical system. If it's a system with a physical output it could cause actual physical damage to people, kill someone, drive a train off the tracks, etc.


  • Some bugs are not the problem, but a symptom of deeply flawed code. The developers are not competent enough and have created a fragile brittle system that can't be added to any more without collapsing. Push down a bubble in one place and it pops up in another.
  • In this case it's more about firing the programmers and doing a major rewrite.


  • Aside from those, it's basically an inconvenience. Prioritize based on soft things like how many people are complaining, what management wants, your own personal feelings, throwing darts at the wall, etc.
share|improve this answer

Something that wasn't said in the current answers: there must be 4 levels. Not 3, not 5, but 4. It's an important number, because then you can't have a "middle". You have to choose if it's less than or more than average.

Something else that wasn't said but has a word:

In project management, there is an often used tool: a risk matrix. It defines risks according to 2 criterion: severity and the probability. This should remind you of other answers in this thread.

share|improve this answer

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