The Differences Between Priority and Severity in Testing

A bug is the most important entity in the software testing life cycle. Priority and Severity are the most important attributes assigned to a bug and yet these are the most misunderstood ones too. When properly used, these properties help in the effective execution of the bug fixing and release scheduling process.

Whenever a new bug is encountered, the bug is logged by a tester or a customer. The attributes attached to the bug could be many like defect description, application version, defect details, steps to reproduce, test data, created by, created date etc. but the severity and priority are the most commonly used ones.

This bug once reported, is going to be referred to by the all other teams that need to know the status of a project, including the testing team, development team, product owner, managers, clients and business analysts.

Let’s understand about severity and priority and their underlying differences.

Note: In this article, we will be using defect and bug interchangeably.

According to ISTQB:

Severity  – “The degree of impact that a defect has on the development or operation of a component or system.”

Priority  – “The level of (business) importance assigned to an item, e.g., defect”. In this article, we will be referring to priority as assigned to a bug or defect only. 

In simple terms, Defect Severity means how badly the defect has impacted the application’s functionality.

Defect Priority defines the order in which defect will be fixed by developers because priority defines the business importance. Higher the impact of the bug on business, higher the priority assigned to the bug.  Let us understand this in detail below.

Severity

Tester decides the severity of a defect. After analysing the impact defect has on the functions of the application, the defect severity can be categorised as:

1. Critical

A defect that has completely blocked the functionality of an application where the user or the tester is unable to proceed or test anything. If the whole application is inaccessible or down because of a defect, such a defect is categorised as a critical defect.

Also, in a production environment, the customer may report bugs, which will be impacting the live application. Such production bugs are also categorised according to priority and severity.

Critical defects should be fixed immediately, because without their resolution either – if the bug was reported in a testing environment – the testing is blocked or – if the bug was reported in production – the users are blocked.

Example – When the login screen of an application is not working and the user is unable to login, the whole application becomes inaccessible to the user.

2. Major

When the whole application is not affected by a defect, however, the major functionalities of a system are not working, such a defect is termed as a Major defect.

There won’t be a complete shut-down of the system as in the case of a critical defect but still, the major and basic functionalities of the application will not be working.

Example – In a banking application, a user is unable to transfer money to any beneficiary, however other functions are working.

3. Minor

The behaviour of the application is not as expected. However, this behaviour does not have any major impact on functionality.

Usually, the minor severity defects have a workaround, so they may not block a functionality completely, unlike major severity defects where there is no workaround.

Such minor defects can wait to be fixed until the next release because they are not restricting the functionality of the application in any way.

Example – The download link of the help section of an application not working, however, the user is able to read the document online.

4. Low

Defects which are not hampering the application functionality at all, are of cosmetic nature and do not impact the functionality or a user directly, however, they are valid defects.

Example – Spelling mistakes on the webpage. They are valid defects but can wait to be fixed since it’s not hampering the application functionality.

Priority

As we have seen earlier, priority means the urgency with which the defect needs to be fixed by the developer. By priority, we indicate the time limit within which the defect needs to be fixed.

The priority can also be changed after comparison with other defects and hence it is subjective in nature. Defect priority categories-

1. High

The high priority defects need to be fixed as soon as possible, a high priority defect impacts the whole application and earliest resolution of such defect is required.

Business impacting defects are usually marked as a high priority because they hamper the revenue and customer base. The timeframe to fix High priority defects is kept to a minimum.

Usually, a high severity means a high priority but this is not always the case.

2. Medium

The defects which are not impacting business and customer fall into the medium category. They are not as urgent as the high priority defects and can wait to be fixed. They can be fixed when the developer has the bandwidth to take them up. Such bugs can be fixed either in the same release or the next.

3. Low

The defects which have the least priority for getting fixed, they are fixed after all the high and medium priority defects are fixed. The fix for low priority defects is usually provided along with some high or medium priority defects’ fixes.

Difference between Priority and Severity

To understand more clearly, let us understand the differences between priority and severity-

 Examples with Priority and Severity combination

To understand the priority and severity better with combinations let’s take the example of a banking application.

1. High Severity and High Priority

The banking application has a login page where the user is authenticated. Steps involved are-

1. The user enters the username and password and clicks on the ‘Login’ button. 
2. The user is navigated to the home page of the user profile.

Now, for example, the ‘Login’ button on the login form is not-clickable. After filling in the login details, the user is not able to click the ‘Login’ button and hence the user is not able to log in. 

This example falls into the category of – High Severity and High Priority. From an application perspective, the whole application is blocked and none of the functions can be accessed by the user, so this is High Severity.

From a business perspective, if any application is not letting users login then what is the use of such an application? Users will avoid such applications and business will be impacted. Such a defect is the High priority defect and needs to be fixed as soon as possible.

2. Low Severity vs. High Priority

On the user home page after login, banking application shows all the options of – Deposits, Transfer, Account Summary etc. In our example, the spelling of ‘Transfer’ is misspelt as ‘Transfer’. This error has no effect on the functionality of the application because the user is able to click and perform a transfer successfully.

However, this is a drawback from the bank’s reputation perspective. Therefore, the severity is Low because functionality-wise there is no issue but the priority is High since it is related to business and needs to be fixed as soon as possible.

3. High Severity vs. Low Priority

For example, there are few actual users who are still using the older IE versions like IE8. The banking application when accessed in older versions of IE, the page is not loaded completely and the form fields are overlapped. This makes the accessibility of the website difficult for IE users using the older versions.

Hence, the severity is high because the whole application is impacted. However, there will be very few actual users who will use IE 8 and other older versions, this makes the priority Low because this fix can wait.

4. Low Severity vs. Low Priority

The ‘Help’ section of the banking website has a subsection, whose theme does not match with the whole website. This defect is not hampering the website functionality, also not many users will access this particular section. Hence, this defect falls under the category of Low Severity and Low Priority.

Check here to see how to add priority to your test cases

Conclusion

Defects and software development move in tandem, as the application grows so does the defect list. For a defect, Priority and Severity are its face value, according to these two values, the fix gets scheduled.

Therefore, it becomes really important that the testers, developers and the whole team understand the proper definition and usage of both these terms. In case of the wrong assignment of priority and severity values to the defect, the whole process of defect fixing will lose its effectiveness.

Which in turn may cause considerable damage to business and may result in financial loss. So, a thorough understanding of the priority and severity is really important for the team to thrive and make better decisions.