Difference Between Defect Severity And Priority In Software Testing

In this post, we see the difference between Severity and Priority. Severity and priority are the two things we have to choose once the bug is found. Whenever we find a bug, we select the bug severity and bug priority. Usually, Testers select the severity of the bug and the Project Manager or Project Lead selects the bug priority. Let’s see bug severity and bug priority in detail.

Check the below video to see “Severity And Priority”

Severity and Priority Infographic:

What is Severity?

Bug/Defect severity can be defined as the impact of the bug on the application. It can be Critical, Major, or Minor. In simple words, how much effect will be there on the system because of a particular defect.

Must Read: How To Write A Good Bug Report

What are the types of Severity?

Severity can be categorized into three types:

As mentioned above the types of severity are categorized as Critical, Major, and Minor

Let’s see how can we segregate a bug into these types:

Critical: 

A critical severity issue is an issue where a large piece of functionality or major system component is completely broken and there is no workaround to move further.
For example, Due to a bug in one module, we cannot test the other modules because that blocker bug has blocked the other modules. Bugs that affect the customer’s business are considered critical

Major:

A major severity issue is an issue where a large piece of functionality or major system component is completely broken and there is a workaround to move further.

Minor:

A minor severity issue is an issue that imposes some loss of functionality, but for which there is an acceptable & easily reproducible workaround.

For example, font family, font size, color, or spelling issue

Trivial:

A trivial severity defect is a defect which is related to the enhancement of the system

What is Priority?

Defect priority can be defined as how soon the defect should be fixed. The main focus on how soon the defect should be fixed. It gives the order in which a defect should be resolved. Developers decide which defect they should take up next based on the priority. It can be High, Medium, or Low.

Most of the time the priority status is set based on the customer’s requirement.

Must Read: Difference between Defect, Bug, Error, And Failure

What are the types of Priority?

Priority can be categorized into three types:

As mentioned above the type of severity are categorized as High, Medium, and Low

Let’s see how can we segregate a bug into these types:

High:

A high-priority issue is an issue that has a high impact on the customer’s business or an issue that affects the system severely and the system cannot be used until the issue is fixed. These kinds of issues must be fixed immediately. In most cases as per the user perspective, the priority of the issue is set to high priority even though the severity of the issue is minor.

Medium:

Issues that can be released in the next build come under medium priority. Such issues can be resolved along with other development activities.

Low:

An issue that has no impact on the customer’s business comes under low priority.

Some important scenarios that are asked in the interviews on Severity and Priority:

#1. High Priority & High Severity

A critical issue is where a large piece of functionality or major system component is completely broken.

For example,

1. The Submit button is not working on the login page and customers are unable to log to the application
2. On a bank website, an error message pops up when a customer clicks on the transfer money button.
3. The application throws an error 500 response when a user tries to do some action.

500 Status Codes:

The server has problems in processing the request and these are mainly server errors and not with the request.

These kinds of showstoppers come under High Priority and High Severity.

Here, there won’t be any workaround and the user can’t do the further process.

#2. Low Priority & High Severity:

An issue that won’t affect customers’ business but it has a big impact in terms of functionality.

For example,

1. Crash in some functionality which is going to be delivered after a couple of releases.
2. There is a crash in an application whenever a user enters 4 digits in the age field which accepts a maximum of 3 digits.

#3. High Priority & Low Severity:

A minor issue that imposes some loss of functionality, but for which there is an acceptable & easily reproducible workaround. Testing can proceed without interruption but it affects customers reputation.

For example,

1. Spelling mistake of a company name on the homepage
2. Company logo or tagline issues

It is important to fix the issue as soon as possible, although it may not cause a lot of damage.

#4. Low Priority & Low Severity:

A minor issue that imposes some loss of functionality, but for which there is an acceptable & easily reproducible workaround. Testing can proceed without interruption.

For example,

1. The FAQ page takes a long time to load.
2. Font family or font size or color or spelling issue in the application or reports (Spelling mistakes of company name on the home page won’t come under this Low Priority and Low Severity)

These kinds of issues won’t bother the customers much.

Some more points:

1. The development team takes up the high-priority defects first rather than of high severity.
2. Generally, severity is assigned by the Tester / Test Lead & priority is assigned by the Developer/Team Lead/Project Lead.

Conclusion

The above are just examples. The selection of severity and priority may vary depending on the project and organization. In Gmail, composing an email is the main functionality, whereas composing an email feature in a banking (email option to send emails internally) application is not the main functionality.