Content

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.

Severity levels

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.

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.

Priority levels

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.

Examples

SCENARIO 1: HIGH PRIORITY & BLOCKER SEVERITY

SCENARIO 2: LOW PRIORITY & LOW SEVERITY

SCENARIO 3: HIGH PRIORITY & LOW SEVERITY