Defect Priority and Severity explained with Examples

 In Software Defect Life-cycle these terms “Defect Priority” and “Defect Severity” play a very key and sensitive role. As Software testers we raise many defects depending upon the nature of the project, but which defect is impacting the system on high level and should be resolved first is decided by Priority and Severity. Let’s first understand the definition :


What is Defect Priority ?

Priority is defined to set the order in which the reported defects should be resolved. Usually Priority is set by Software Tester or QA Lead and developers focus on higher priority defects first following the descending order. Priority can be categorized in three layers.


– High Priority (P1) :

Defects falling under P1 category must be resolved and closed as soon as possible. Due to such defects testing of entire application is blocked and Tester can not move any further.



– Medium Priority (P2) :

Once all the defects with High priority are resolved, next focus should be on Medium level defects. Normally functional defects such as a feature is not working as it is supposed to be, major cosmetics errors, validation errors are considered as Medium priority defects. Such issues don’t stop you to perform further testing.


– Low Priority (P3) :

These defects are taken into consideration once all High & Major priority defects are resolved. Minor UI issues, spelling mistakes, alignment issues, color code mistakes should be considered as Low priority defects.


In short, by providing Priority to a Defect we set the order in which all the reported defects to be resolved.


What is Defect Severity ?

Every defect impacts on the system at some level. This impact is measured by the “Severity” parameter. Severity type is categorized by Software Tester based on the Test Case and functional / requirement understanding. It also indicates the seriousness of the issue occurring on the application. Each Defect management tool categories Severity in different way.


– Blocker Severity :

A defect that completely crashes the system and Tester is no longer able to move further with the testing. In another scenario when whole feature / functionality is missing from the application, this can be considered as a Blocker defect. Almost all the time Blocker severity defects are having highest priority.


– Critical Severity :

A highly severe defect causing the system failure or functionality collapse. But user is able to access some of it’s functions or the same scenario is executable some other way. Almost all the time Critical severity defects are having highest priority.


– Major Severity :

Defect falling under Major severity is generally functionality specific defects. It does not cause any system failure kind of situation. But such defects are equally important and they should be resolved without any unnecessary delay.


– Minor & Trivial Severity :

Defects having small UI issues, spelling mistakes in content, minor alignment issues, color shades are reported as minor or trivial defects. These issues do not affect any of the functionality and keeping they open long time won’t make any difference.


Now let’s understand combination of Priority and Severity through some examples.


Scenario 1 : High Priority & Blocker Severity

– A very common example, User is not able to Login into application with proper credentials. This is a very critical scenario which needs to be fixed as soon as possible.

– In an E-Commerce website User is not able to add the produce into the Cart / not able to check-out for payment from the cart. If occurred on the live application, this issue can impact on the business at great level.

– After registration, User is not getting the Link to complete the registration process.

– System is crashed when providing invalid keywords(e.g: XSS scripts) in the Search box.


Scenario 2 : Low Priority & Low Severity

– Minor spelling mistakes on the pages like “Site Map”, “Career” or “Company Blog” pages.

– Color of the button on About Us page is slightly different.

– Minor alignment issues in the content of the Company Blogs page.


Scenario 3 : High Priority & Low Severity

– A very common example, “Company Logo” is not displayed as expected. This defect is not affecting any functional scenarios but it can impact on the company’s brand value. So this issue should be fixed without any delay.


This is all about defect priority and severity. Please share your experience and provide more examples via comments.

No comments:

Post a Comment