Severity and Priority in Software Testing

What is Severity?

Severity is the extent to which a particular defect can impact the software. Severity is a parameter to denote the implication and the impact of the defect on the functionality of the software. 

  • A higher effect of the bug on system functionality will lead to a higher severity level.
  • A QA engineer determines the severity level of a bug.

Types of Severity:

Severity in software testing can be classified into four categories:

  • Critical: This severity level implies that the process has been completely shut off, and no further action can be taken.
  • Principal: This is a significant flaw that causes the system to fail. However, certain parts of the system remain functional.
  • Medium: This flaw results in unfavorable behavior, but the system remains functioning.
  • Low: This type of flaw won’t cause any significant breakdown in the system.

What is Priority?

Priority is a parameter that decides the order in which a defect should be fixed. Defects having a higher priority should be set first. 

  • Defects/ bugs that leave the software unstable and unusable are prioritized over the defects that cause a small software functionality to fail.
  • It refers to how quickly the defect should be rectified.

Types of Priorities:

Priority in software testing can be divided into three categories:

  • Low: The defect is irritant, but a repair can be done once the more severe defects can be fixed.
  • Medium: The defect should be resolved during the ordinary development course, but it can wait until a new version is created.
  • High: The defect must be resolved as soon as possible as it severely affects the system and cannot be used until fixed.

Examples of Priority and Severity Combination

There are possible combinations of priority and severity:

1. High Severity High Priority: Consider an example of a web application where if, after filling in the login details, the user cannot click the login button, then this is the case of high severity and high priority.

  • High Severity: If the login button is not clickable, then the whole application is blocked, and the user can access none of the functions
  • High Priority: If the login button is not clickable, the application is not letting any user login. Then what is the use of such an application? Such defects are high-priority, as the users will avoid such applications, and businesses will be impacted.

2. High Severity Low Priority: Consider the example of the application being used on the older versions of Internet Explorer, say IE8. This is a case of high severity and low priority.

  • High Severity: The fault, in this case, is of high severity because when the application is accessed on the older version, the page will not load correctly, and a few fields and text will overlap; thus, the whole application will be impacted.
  • Low Priority: The defect is a low priority because very few users use IE8 or older versions so the fix can wait.

3. Low Severity Low Priority: Consider the example of the help or FAQ section of the website where the theme or font style of a section does not match that of the rest of the page.

  • Low Severity: The defect is of low severity as the defect is not affecting the website functionality.
  • Low Priority: The defect is low priority as only a few users will access this particular section of the website, so that the fix can wait.

4. Low Severity High Priority: Consider the example when there is a typo on the website. For example, the case of the school website where the ‘Admission Form’ is misspelled as ‘Admission Form.’ 

  • Low Severity: The defect is low severity because there is no functionality issue.
  • High Priority: The defect is highly prioritized since it relates to business and must be fixed as soon as possible.

Defect Triage

Defect triage prioritizes each defect based on its severity, frequency, risk, etc. The goal is to evaluate, prioritize, and assign the resolution of defects. This is mainly used in agile project management. The defect triage meetings frequency depends on several factors:

  • Project schedule.
  • Overall project health.
  • The number of bugs in the system.
  • Impact on schedules of team members’ availability.

The defect triage process can be summarized as follows:

  1. Defect Review: This step involves reviewing all the defects, including those rejected by the team.
  2. Defect Assessment: This step involves an initial assessment of the defects based on the content and respective priority and severity settings.
  3. Defect Assignment: This involves prioritizing the defects and assigning the defects to the correct release by the product manager.