The Differences Between Priority and Severity in Testing

The Differences Between Priority and Severity in Testing

| March 6, 2020

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

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 severity and priority are the most commonly used attributes. They help teams efficiently fix bugs and go through the release scheduling processes, without letting any critical issues fall through the gaps.

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

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

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

According to ISTQB:

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

Priority is “the level of (business) importance assigned to an item, e.g., defect.
In this article, we will refer to priority as assigned to a bug or defect only. 

Defect Severity means how badly the defect has affected the application’s functionality.

Defect Priority defines the order in which defect will be fixed by developers (because priority defines the business importance). Note that the higher the impact of a bug on the bottom-line of a business, the higher the priority assigned to it.  Let us understand this in detail below.

Severity

Tester decides the severity of a defect. After analyzing the impact a defect has on the functions of the application, the defect severity can be categorized 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 categorized as a critical defect.

In a production environment, bugs that are affecting the live application and its UX may be reported by the customers. These bugs are also categorized by their priority and severity.

It goes without saying, but regardless of who reports the bug, critical defects should be fixed immediately. If the bug was reported in a testing environment – the testing is blocked until the bug is fixed. If the bug was reported in production – the users are blocked from being able to fully use your application.

 For instance– 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 a bug isn’t affecting the whole application but still prevents major functionalities of a system from working, it becomes a Major defect.

  There won’t be a complete shut-down of the system (which would be the case for a critical defect). Even so, it will prevent major, sometimes even basic functionalities of the application from working.

For instance, in a banking application, a user is unable to transfer money to any beneficiary but that doesn’t affect their ability to add new beneficiaries.

3. Minor

The behavior of an application is not as expected, but this does not affect functionality.

Usually, 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.

For instance, the download link in the Help section of an application is not working. However, the user is still able to read the document online.

4. Low

Defects of cosmetic nature that don’t affect the application functionality or UX directly. But they are valid defects nonetheless.

For instance, spelling mistakes on the webpage. These are valid defects, but they can wait to be fixed since they’re not affecting application functionality.

Priority

By now you know that Severity means the urgency with which the defect needs to be fixed by the development team. Priority, on the other hand, answers how quickly the defect needs to be fixed.

Note that the priority can change relative to other defects, hence it is subjective in nature. Defect priority categories-

1. High

If a defect affects bottom-line or UX directly, it is marked high priority. These bugs may affect the whole application. They need resolution as soon as possible, and assigning a high-priority to them ensures that the time-to-resolution is low.

Usually, a high severity means a high priority as well. But this is not always the case.

2. Medium

The defects which don’t affect business and customers typically get Medium priority. They are not as urgent as the high priority defects and can be fixed when the development team 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.

Priority and Severity are critical in a bug report for any tester. But there’s yet more that goes in it. See what else goes into writing a well-rounded bug report.

Difference between Priority and Severity

Now that you understand what each of them really mean, let us look at finer differences between priority and severity-

 SL.NOSeverityPriority
1.Defined by the impact on the application’s functionality.Defined by the impact on business.
2. Category decided by testers.Category decided by developers or product owners.
3.Deals with the technical aspects of the application.Deals with the timeframe or order to fix the defects.
4.The value does not change with time, it’s fixed.Value of priority is subjective and may change after comparison with other defects.

Examples with Priority and Severity combination

Usually, bugs in the most critical user paths in the application are clarified as high severity and high priority bugs. Hence it is recommended to test all these cases for every change in the product every time.

With Regression testing, these bugs can be identified early in the cycle. If the releases are frequent and the regression testing is done manually there is a very high chance of missing some of these bugs. The automation approach is best suited here. With the right test automation tools, the high severity and high priority ups can be found automatically right from the beginning. 

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.

These issues are also called blocker issues because they prevent the user from working further and need urgent fix.

The most common place for these high severity and high priority bugs is the critical user path – a path that a typical user will go through every time they use the application. And the good news is that these bugs can be easily avoided if they are caught before they go to release. The solution is automation for the regression test cases for the critical user path.

For automation, you need an automated testing tool that allows you to easily automate the critical user path. Testsigma is one such tool that has made it extremely easy for a tester to automate the regression test cases without any hassles.

2. Low Severity vs. High Priority

Sometimes browsers render the pages differently, the same page may look different in other browsers, elements may miss places, text wrapping doest look good, key buttons are not displayed properly, functionality works but the user experience is not good or even bad. These low severity but high priority wrt to user experience.

It is important to test applications across browsers and OS to catch these types of bugs. To catch these bugs automatically and quickly before they may be seen by a customer is to automate them via a tool that supports extensive cross browser testing.

To save your time and manual testing effort – you need a tool that can let you execute these test cases on a broad set of browsers and devices, according to what your customers might be using. Testsigma is one such tool that lets you automate your test cases in simple English and lets you run them on an extensive number of browsers and devices. Thus, while you waste no time in automating the test cases, the execution can be setup without any hassles. Also, the tests are executed in parallel to save your precious time.

Lets go through a specific example – 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.

This is a mobile specific issue but could have been easily avoided if they mobile testing was automated.

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.

To catch such bugs before the customer catches them, it becomes essential to execute test cases on old browser versions too. This is where an automated testing tool for cross browser testing comes into the picture.

Try Testsigma to access all the older versions of browsers, not just that Testsigma is an end-to-end test automation platform. No coding skills required!

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 in Testsigma.

Conclusion

Classifying the bugs with the right priority and severity is important. In the testing process, there has to be a common reference to classify these bugs. Test Cases/Test Manager tools are the correct reference to classify bugs correctly. If the test cases(both manual and automated) are marked with correct severity, in the beginning, it will help the testers classify the bugs correctly while testing.

If both manual and automated process and in place, in many cases automated tests are not marked properly, and when there is a failure the one who is executing and analyzing the results may not have full context and ends up filing a bug with incorrect priority and severity. 

It is important to mark these correct at the Test Cases level itself for both Manual and Automated tests.

Testsigma is one such test automation platform designed with integrated Test Management for both Manual and Automated testing.

You can use Testsigma for Manual Testing, Automated Cross-Browser Testing, Automated Regression Testing, Automated Web Application Testing, Automated Mobile App Testing, etc.

Suggested Reading :

https://testsigma.com/blog/techniques-to-prevent-software-bugs/
https://testsigma.com/blog/how-to-write-a-good-bug-report-some-tips/
https://testsigma.com/blog/common-software-testing-mistakes-beginners-make-how-to-avoid/

Also check our round-up blog where we talk about how to make a transition from manual to automation testing.