Bug / Defect Priority vs Severity Matrix

In Software Testing, deciding how important the defect is and how soon the defect should be fixed is as important as finding a defect! This depends on how you actually place the defect into Priority-Severity matrix.

I have come across a lot many test engineers, who get confused between priority and severity of a defect. Definition is important but understanding is even more important.

Definitely customer (guidelines) plays a major role in the decision but I’d like to convey in terms of the general scenario. I’d like to add some easy words to clarify the confusion (probably forever).

What is Defect Priority

Priority is something that is defined by business rules. It defines how important the defect is and how early it should be fixed.

What is Defect Severity

Severity is defined by the extent of damage done by the defect. It defines how badly the defect affects the functionality of the software product.

Again you’re fed with another definition? No!! Let’s take some examples…

They say a picture is better than a thousand words:

Priority Severity Matrix


High Priority and Low Severity example

Company logo is half cut on the home page of its website. This is high priority defect because displaying an incomplete company logo would put bad impression on business as this would defame the company or website. So, this defect should be fixed as soon as possible.

As far as severity is concerned, this defect has got low severity because it is not impacting any functionality of the website.

High Priority and High Severity example

Login button is not clickable on the login page of a web application. This is a high priority defect because this is stopping users from using the site. So, this should be fixed at once.

At the same time, this defect is of high severity because none of the other functionalities can be carried out.

Low Priority and High Severity example

A twisted scenario which rarely occurs but makes the application crash is an example of a low priority defect because user doesn’t come across this scenario normally and can be fixed later.

On the other hand, it is having high severity because it makes the whole application break and no functionalities can be performed.

Low Priority and Low Severity example

Spelling mistake in any of the words on some inner pages of the website that is rarely accessed is an example of low priority defect because it doesn’t matter much to the users as business is not impacted and can be fixed later. It is also having low severity because it is not impacting any functionality of the website.

I hope this clears the defect attribution. comments and questions are welcome.

Leave a Reply

Your email address will not be published. Required fields are marked *