Difference between severity and priority in defect report – finally revealed

When talking about defects (or also called “bugs”), tell me if this sounds familiar to you:

You found a bug that crashes the system.

You immediately submitted to the bug tracking system.

You are waiting for emails or comments to thank you for finding this awesome problem and the problem will get fixed immediately.

You wait…wait…and wait…and that did not happen.

“How come? This bug crashed the system, but no one cares to fix it?” You wondered (and a little bit upset)

You wrote up a follow-up email and added comment to the bug in the tracking system. You were then told that it’s a low priority defect and it would be fixed when having time.

#Facepalm #heartbreaking

This turned you off completely. You got frustrated and not sure what was going on.

If this sounds similar, I hear you. I was there, done that.

While I share your feeling, I realize that one of the reasons was that you might set the wrong priority or severity of your bug. But that’s not just you. Testers make such mistake all the time (me included). They can’t tell the difference between severity and priority of defect and they don’t know how to the value the right way.

In this post today, I would like to share with you everything (I hope so) you need to know about severity and priority of a defect, the difference between the two and how to set values the right way.

Alright, let’s make it.

What is severity of a defect?

In a nutshell, severity of a defect will tell you how severe your defect is *technically* or in other words how bad the problem is.

How to know how bad the problem is?

Remember the definition of bug?

Bug is “Anything that threatens the value of the product” as James Bach defines it.

So how bad the problem is is closely related to how bad the problem threatens the value of the product. For example:

• System crashes, so system is useless ==> The severity is really critical. It’s a road-block.
• Galaxy Note 7 battery is exploded ==> The severity is really critical. It’s a safety matter.
• There’s a typo in a warning message ==> The severity is trivial. The typo may annoy users a little bit, but it’s okay because a warning message works as expected.

You got the idea.

Here’s common severity of a defect:

1. Critical – System or application crashes and doesn’t work at all. There’s no workaround either. It’s a showstopper and system is useless if this problem doesn’t get fixed
2. Major – Major function or component of the system does not work as expected. There may be a workaround
3. Minor – Minor function of component of the system does not work as expected
4. Trivial/cosmetic – Typo, inconsistency in look and feel, enhancement, etc.

Also noted that these are not “set in stone” severity options. Your company may have more or less severity options or they may define severity options differently, so keep eyes on that.

What is a priority of defect?

In theory, all reported bugs need to be fixed, but in practice, not all bugs will be fixed. Here’s why:

• Project does not have enough time and resource to fix all the bugs.
• It’s costly to fix all the bugs.
• Not all bugs make sense to be fixed.
• Ship it! Letting the product go out of doors is more important than making it perfect.

Whatever the reason is, fixing all bugs is an unrealistic goal…and this boils down to this question:

Which one to fix first and which one to fix later? That’s where priority of a defect comes in to help answer that question.

Simply put, priority of a defect will tell you how urgent to fix a defect, which one to fix first and which one to fix later.

Knowing which defect to fix first and which one to fix later is a bit tricky because it depends on different business aspects:

• Project milestones/phases: What’s the goal/requirements of coming release?
• Cost and resources: How much time and resource the project has
• Risk: What risk involved if the defect doesn’t get fixed
• Severity of defect: How bad the problem is

As you can see, setting the priority of the defect is complicated and it’s basically a business driven decision.

Here are some common priorities of a defect:

• Urgent: Fix immediately
• High: Fix in coming release
• Normal: Fix in next release
• Low: Fix when having spare time

Again, these are not “set in stone” values. Your organization may define things differently, but the idea is the same. Priority will indicate how urgent to fix a bug.

Can testers set the priority of a defect?

Testers are asking this question all the time…and here’s my answer:

“Yes…but it depends” (Sorry, this sounds like consulting :D). It depends on:

• How much you understand the business so that you can give your opinion.
• How much you are involved to do that

That fact is that many testers do not know (or care to know) about other businesses of the project other than their daily tasks such as writing and executing test cases, finding and reporting bugs. When they set the priority of a defect, they don’t take into account of other business aspects such as the milestone, the customer, the risks, etc. As a result, they set wrong priority.

Needless to say, in some organizations, testers are not allowed to set the priority of a defect. Sometimes, it’s just part of the testing process. So, just accept that.

The bottom line is:

If you are allowed to set the priority of a defect, just do that. Make sure you take into account of other business aspects when you set the priority. If you are not allowed, try to learn, understand the business to build trust first so that you are then invited to do that.

Also, there’s another concern:

Is there any correlation between severity and priority?

In other words, if the defect has high/ severity, does it always have high priority?

My answer is yes, there’s a correlation between severity and priority, but not always.

Let me give you some examples:

Example of high severity and high priority

Problem: The system crashes when user launches it

Severity is Critical because the system crashes

Priority is Urgent because it blocks the end user from using it. We can ship the product with this problem.

Example of low severity and high priority

Problem: Company slogan has a typo

Low severity: It’s a trivial typo issue. Users can still use the system as normal

High priority: The priority to fix is high because this type of typo may give a bad impression for end-users and may cause bad branding issues. Also, this problem is an easy fix for developers.

Example of high severity and low priority

Problem: The system crashes intermittently when user enters negative value for Age field

Severity is High because the system crashes.

Priority is Low because 1) it doesn’t always occur and 2) it’s unlikely for users to enter negative value into the Age field

Who decides severity and priority in testing?

The process to do that may be different from project to project, but here are common process:

Testers will set severity when they report the defect

Testers optionally will set the priority when they report the defect

In bug triage meeting, a project manager will review these bugs with developers, testers, BA to decide the final priority of a defect.

Severity and Priority are subjective and confusing by themselves

Regardless of how clear the instruction or guide is, severity and priority are still confusing and subjective.

What I mean is:

How critical is Critical? How high is High?

What means “major” to me does not mean major to you.

The bug priority is low today does not mean it will be low tomorrow.

The best you can do is to follow the guideline to create consistency in the way you communicate in a bug report, but you also need to be ready to make changes in severity and priority and accept that.

Wrap-up

I have just shared with you the difference between severity and priority of a defect, how to set the values the right way. Secret is now finally revealed :D. I hope that after reading this guide, you will have a clearer understanding about priority and severity. Remember that at the end of the day, it’s not how well you set the priority or severity of the defect. It’s how well you communicate the problem, the risks to team to get problems fixed.

Related read: Why your bug report sucks (and how to fix it)

Want to say something about this post, severity and priority, add your comment below.