09 Oct

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.

Definitly 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).

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.

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:

defect-priority-severity-matrix

High Priority and Low Severity:

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:

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:

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:

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.

-- Kedar Vaijanapurkar --