Lets imagine a company uses a bug severity of four levels for this post.

  • Critical – Bug renders product/feature unusable and testing cannot proceed on one or more features
  • Serious – As critical, but a work around exists allowing for restored functionality or testability
  • Medium – Bug effects functionality, but only in a limited portion of a feature; the remainder of the feature is usable/testable
  • Low – Bug does not effect functionality (cosmetic items fit in here)

When a person logs a bug in their product, they assign it a severity based upon some set of criteria. Usually it is one of the following.

  • A defined set of requirements – ex: It is critical if it brings either the machine or testing to a halt
  • Area expertise – ex: a security guru could recognize the ramifications of something seemingly innocent
  • Product expertise – ex: a tester has been with a particular product for 6 years and knows pretty much all the effects a bug will have on the product
  • How much it frustrates/annoys them – ex: A small bug might get logged at a higher severity if the person is frustrated

Ideally you would want to have a combination of the first three and as little of the last as possible.

From there, someone will assign it a priority. This is the order in which the person assigned to the bug is to go through their bug box. Deal with all higher level bugs before moving to the next level. Notice that the assignee does not address their work based upon the severity. This leads us to

Adam’s First Law of Bug Levels: The level at which you submit a bug at is irrelevant.

This is almost heretical, but makes sense if you think about it. The person (or group of persons) who is responsible for setting the priority needs to understand the product in order to set it. They therefore use their knowledge of the affected system and their own opinion to give it a weighting not the severity that it was logged at. It could be argued that using the severity as an input to that decision could skew the decision incorrectly. ex: “Well, Adam says it is a high and he is an outstanding tester” could taint if a bug is a medium but I have some agenda I am trying to push or I could just be cranky.

Over time, a pattern will evolve over time regarding which bugs are addressed and which are not as biases become recognized in prioritization, staffing skills are known and observation of the bug system. Once this pattern is known, the next Law of Bug Levels starts to apply.

Adam’s Second Law of Bug Levels: There are really only two severities for bugs; Fix or Don’t Fix (this could also be “I need this fixed” and “I can live with it” but “Fix” and “Don’t Fix” are catchier)

This one can send managers into fits. Critical and Serious are by very definition in the Fix category, so why bother having to decide whether it is a Critical or Serious (it is not often cut-and-dry). Medium and Low have a bit of movement as to which severity they get, but remember that this Law comes into effect over time and after a precedent is created so the choice is likely to be the correct one.

Much like severities, most places have at least 3 priorities: High, Medium and Low (or some variation thereof). You might see where I am going with this.

Adam’s Third Law of Bug Levels: There are really only three priorities for bugs: Fix Now, Fix Later and Never Fix

What is the difference between two bugs assigned to you at the same priority? Who knows? Ultimately you will need choose one to Fix Now, and leave the other for Later. A common argument against this is that you cannot easily load developers up with bugs to fix. Great! Giving your developers a tonne of bugs in their queue is just distracting. At most give them 3, but ideally you should give them 2: a Fix Now and a Fix Later. If something should come in between the time you last assigned them a bug that needs to be addressed quickly, remove their Fix Later and give them the new one as a Fix Later (pulling them off what they are fixing now is not worth the loss of productivity that results in most cases). This way they always know what they are to be working on at present, and what they are working on next. It is irrelevant what they are slated to work on 6th or 7th as that is likely to change.