Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 6 down vote favorite

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
9  
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
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
show 1 more comment

10 Answers

up vote 8 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
up vote 6 down vote

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
up vote 2 down vote

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
up vote 2 down vote

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
up vote 2 down vote

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
up vote 1 down vote

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
up vote 1 down vote

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: en.wikipedia.org/wiki/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
show 2 more comments
up vote 1 down vote

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
up vote 1 down vote

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
up vote -2 down vote

You can use the standard of log level, in my point of view it is the best solution. An example with Log4j

share|improve this answer
This is about bug reports, not logging – TheLQ Mar 11 '11 at 15:52

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.