Difference Between Priority vs Severity in Testing

In this article, we will see the difference between Priority vs Severity in Testing, what is Priority, what is Severity, and what types.

Priority and Severity in Testing

A bug is the most important body in the software testing life cycle. And the most important essence that can be assigned to a bug is Priority and Severity.

Severity and Priority are the most frequently used attributes because whenever a new bug is encountered, the bug is logged by a tester or a customer, and the attributes related to the bug could be many like defect description, application version, defect details, steps to reproduce, test data, created by, created date, etc. So, Severity and Priority help teams efficiently fix bugs and go through the release scheduling processes, without letting any critical issues fall through the gaps.

What is Severity?

The impact of the bug/defect on the application is known as the severity of blocker defects and what is the impact of the defect on the whole system’s functionality. The severity is a parameter set by the tester while opening a bug/defect and is essentially in control of the tester.

What is the priority?

Priority defines in which order we should resolve a defect. Should we fix it now or later, or can it wait? This priority status is confirmed by the tester to the developer mentioning the time frame to fix the defect. If high priority is specified then the developer has to fix it as soon as possible. The priority status is determined based on the customer’s requirements.

Types of Severity

There are four different levels of severity.

1. Critical
2. Major
3. Minor
4. Low

1. Critical

A defect that completely blocks the testing of the product/feature is a critical defect. If the application crashes or becomes unusable/not able to proceed further, the defect could be classified under critical severity.

For example, in an email services provider like Yahoo or Gmail, after typing the correct username and password, instead of logging in, the system crashes or throws an error message, This defect is classified as critical as this defect makes the whole application unproductive.

2. Major

Any Major feature implemented that does not meet the customer’s requirements/use case(s) and behaves differently than expected, can be classified under Major Severity.

For example, in an email service provider like Gmail, when we are not allowed to add more than one recipient in the CC section, this defect is classified as a Major defect as the major functionality of the application is not working perfectly.

3. Minor

A medium defect appears when the product or application doesn’t meet certain criteria or still exhibits some strange behaviors, however, the functionality as a whole is not impacted and can be classified under Minor Severity.

For example, in an email service provider like Gmail, there is an option called “Terms and Conditions” and in that option, there will be multiple links regarding the terms and conditions of the website/application, When one among the multiple links, is not working fine, it is called as Minor severity as it only affects minor functionality of the website/application and it doesn’t have a big impact on the usability of the website/application.

4. Low

Any corrective defects including spelling mistakes alignment issues or font casing can be classified under Low Severity.

For example, in an email service provider like Gmail, we would have noticed the “License page”, if there are any spelling mistakes or misalignment on the page, this defect is classified as Low.

Types of Priority

There are three types of priority

1. High
2. Medium
3. Low

1. High

It has a major impact on the customer application, and it must be resolved as soon as possible as it affects the system badly and cannot be used until it is fixed.

2. Medium

The defect should be fixed before the release of the current version in development. It means during the normal course of the development activities defects should be resolved.

3. Low

The flow should be fixed if there is enough time, but it can be deferred with the next release. It means the defect is a burden but a repair can be done once the more serious Defect has been fixed.

Priority vs Severity: Key Difference

The difference between priority vs severity is as below:

Example of Defect Severity and Priority

Examples of Defect Severity and Priority are as below:

1) High severity and High priority

The user is not able to log in to the application with a valid username and password credentials. This is a very critical scenario and this needs to be fixed as soon as possible.

2) Low priority and Low severity

If any form of the website has a spelling mistake, this defect is set as Low Severity and Low Priority.

3) Low severity and High Priority

The logo of the company on the front page or home page is displayed wrong in the application, this defect is set to be a High Priority and Low Severity defect.

4) Low Priority and High Severity

There are some buttons on the website or application which are overlapping. Even if clickable, are creating a hassle.

What is Defect Triage?

In Software Testing the term Triage is used to define the severity and priority of defects. Defect triage is a process or mechanism where each and every defect is prioritized based on its severity, risk, frequency, etc.

In Software Testing, we use the word Triage with the merger of Defect/Bug like Bug Triage or Defect Triage. Here we apply the same approach to bugs found during the testing phase. It is to decide the priority of the defect/bugs based on their severity, risk, frequency, etc.

In Software Testing, Defect Triage comes into the picture when there are no sufficient resources to handle the bug/defects. Imagine a situation where there are a number of defects that are more as compared to the resources to handle those that are limited. In this case, defect triage helps to get as many defects resolved as possible by determining the defects and prioritizing them based on the severity defects.

The triage process includes the below steps:

• Reviewing all the defects along with rejected defects by the team.
• Basic assessment of the defects is based on their content and respective priority and severity settings.
• Prioritizing the defect based on the inputs.
• Assign the defect to the correct release by the product manager.
• Re-direct the defect to the correct owner/team for more action.

Conclusion

In Software Engineering, while opening defects it’s a tester’s duty to assign the right severity to the defects because assigning the wrong severity to the defect can delay the STLC process and can have some forceful implications on the overall performance of the team.

Read Also:-

1) 15+ Bug/ Defect Tracking Tools

2) Bug Vs Defect – What’s the Difference

3) How to Write a Good Bug Report?