Bug – Severity and Priority

Severity and priority go hand in hand. Often there is a misconception about it.

What should be the severity and priority of the bug? Sometime developer does not agree with the severity and priority given to the bug.

Is it possible to change Severity and Priority of a bug during the bugs life cycle?

Priority – Yes and Severity- NO

Why?

“Severity” is the noun associated with the adjective, “severe”. Severity, with respect to a bug, is basically how big a bug is and how much trouble it is going to cause.In other words, severity is about risk a bug poses if the application with the bug is released to customer.

We assess risk of a bug by asking questions like

• What impact the bug can cause and the probability of occurring?
• How much harm could this bug cause to something the customer cares about?
• How likely is this bug to manifest and how likely is that harm to occur if it does?

When we are testing, and we think we see a problem but we do not see everything about that problem. We see what some people call a failure, a symptom. The symptom we observe may be a manifestation of a coding error, or of a design issue, or of a misunderstood or mis-specified requirement. We see a symptom but we do not see the cause or the underlying fault. Whatever we are observing may be a terrible problem for some user or some customer somewhere—or the customer might not notice or care.

It is easy to believe that a serious problem will always be immediately and dramatically obvious. It is also easy to believe that a problem that looks like big trouble is big trouble, even when a fast one-byte fix will make the problem go away forever. We also become easily confused about the relationship between the prominence of the symptom, the impact on the customer, and the difficulty associated with fixing the problem, and the urgency of the fix relative to the urgency of releasing the product.

Most organizations have standard criteria for classifying bug severity

• Severity 1 or S1 or Showstopper – Catastrophic bug or showstopper. Causes system crash, data corruption, irreparable harm, blocking further testing of the module/application etc.
• Severity 2 or S2 or High Severity – Critical bug in important function. No reasonable workaround. Bugs related to data security, integrity problems, and inaccessibility and batch job aborts, errors causing system reloads that prevent a customer from conducting business or prevent to use the application.
• Severity 3 or S3 Medium Severity – Major bug but has viable workaround.
• Severity 4 or S4 or Low Severity – Minor bug with trivial impact.

As for priority: priority is the order in which someone wants things to be done. “Priority” is a tester’s assessment of how important it is to fix the problem—a kind of ranking of what should be fixed first. Again based on my experience, I do not see this as being a tester’s business at all.

Deciding what should be done on a programming or business level is the job of the person with authority and responsibility over the work, in collaboration with the people who are actually doing the work. When I am a tester, there is one exception: if I see a problem that is preventing me from
doing further testing, I will request that the fix for that problem be fast-tracked (and I’ll outline the risks of not being able to test that area of the product). Deciding what gets fixed first is for those who do the managing and the fixing.

Priorities can be classified as high, medium and low. Sometime it is also denoted by P1, P2, P3 and P4.

Theoretically, bug severity does not change. The potential for business or technical impacts stays pretty much the same throughout the development project. It is same as if you encounter a severe accident, the severity of the accident will never change.

Priorities for fixing bugs do change depending on where we are in the project. Initially it is tester’s priorities but as we inch closer to the release date, customer’s priority becomes more important. Consider the example, tomorrow you have an important meeting with client. In the morning you get up and while you are about to move out, you get a call from your friend that he has met and accident and require your immediate help. Now you need to re-prioritize your tasks and put the meeting low priority with respect to helping your friend and schedule the meeting for some other time. Same is with bug.

This answers the initial questions.