Severity in Testing vs Priority in Testing

In software testing, a bug is the most critical entity. The most important attributes that can be assigned to a bug are priority and severity. They help teams to efficiently fix bugs and go through the release scheduling processes without letting any critical issues fall through the gaps. The article focuses on discussing the difference between Severity and Priority in testing. 

What is Severity?

Severity is defined as the extent to which a particular defect can create an impact on 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 4 categories:

• Critical: This severity level implies that the process has been completely shut off and no further action can be taken.
• Major: 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 major breakdown in the system.

What is Priority?

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

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

Types of Priorities:

Priority in software testing can be divided into 3 categories:

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

Severity vs Priority

Below are the differences between severity and priority:

Features	Severity	Priority
Definition	Severity is a parameter to denote the impact of a particular defect on the software.	Priority is a parameter to decide the order in which defects should be fixed.
Purpose	Severity means how severe the defect is affecting the functionality.	Priority means how fast the defect has to be fixed.
Relation	Severity is related to the quality standard.	Priority is related to scheduling to resolve the problem.
Categories	Severity is divided into 4 categories: Critical Major Medium Low	Priority is divided into 3 categories: Low Medium High
Who decides defects?	The testing engineer decides the severity level of the defect.	The product manager decides the priorities of defects.
Value	Its value is objective.	Its value is subjective.
Value change	Its value doesn’t change from time to time.	Its value changes from time to time.
Association	It is associated with functionality or standards.	It is associated with scheduling.
Indication	It indicates the seriousness of the bug in the product functionality.	It indicates how soon the bug should be fixed.
Driving factor	It is driven by functionality	It is driven by business value.
Based On	It is based on the technical aspect of the product.	It is based on the customer’s requirements.

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 the 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 none of the functions can be accessed by the user
• High Priority: If the login button is not clickable this means that the application is not letting any user log in then what is the use of such an application? Such defects are high-priority defects 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 properly and a few fields and text will be overlapped thus whole application will be impacted.
• Low Priority: The defect is of low priority because very few actual 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 of the page does not match with 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 of low priority as not many users will access this particular section of the website so 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 of low severity because functionality-wise there is no issue.
• High Priority: The defect is of high priority since it is related to business and needs to be fixed as soon as possible.

Defect Triage

Defect triage is the process where each defect is prioritized 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 a number of 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:

1. Defect Review: This step involves reviewing all the defects including the defects that were 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.