The Differences Between Priority and Severity in Testing

A bug is the most critical 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.. Still, 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 will be referred to by other teams that need to know the project’s status, including the testing and development teams, product owners, managers, clients, and business analysts.

Let’s understand what makes severity and priority stand out from each other

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 meaning the level of (business) importance assigned to an item, e.g., defect.

This article will refer to priority as given 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 developers will fix defects (because priority describes business importance). Note that the higher the impact of a bug on a business’s bottom line, the higher the priority assigned to it. Let us understand this in detail below.

Severity Meaning

Severity Means the severity of a defect the tester decides. After analyzing a defect’s impact on the application’s functions, 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 cannot proceed or test anything. If the whole application’s functionality is inaccessible or down because of a defect, such a defect is categorized as a critical defect.

The customers may report bugs affecting the live application and its UX in a production environment. 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 use your application thoroughly.
 For instance– When the login screen of an application is not working and the user cannot log in, the whole application becomes inaccessible to the user.

2. Major

 When a bug isn’t affecting the whole application but still prevents significant system functionalities from working, it becomes a Major defect.

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

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

3. Minor

The behavior of an application is different than 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 until the next release because they do not restrict the application’s functionality.

For instance, the download link in the Help section of an application needs to be fixed. 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. 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 Meaning:

By now, you know that Severity means the urgency with which the defect needs to be fixed by the development team. Priority, however, 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 directly affects the bottom line or UX, it is marked as a high priority. These bugs may affect the whole application. They need resolution as soon as possible, and assigning a high priority ensures low-resolution time.

Usually, a high severity means a high priority as well. But this is only sometimes the case.

2. Medium

The defects which don’t affect business and customers typically get Medium priority. They are less urgent than 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 that have the least priority for getting fixed are fixed after all the high and medium-priority defects are fixed. The fix for low-priority defects is usually provided along with some tall or medium-priority defect fixes.

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

Difference Between Severity and Priority

The difference between Priority and Severity are the metrics that indicates the overall impact and the order in which the problems should be addressed. Severity is related to quality standards where priority is associated with scheduling defects to resolve them in software.

Now that you understand each, let us look at the finer differences between priority and severity-

SL.NO	Severity	Priority
1.	Defined by the impact of a specific problem on any 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.	The priority value is subjective and may change after comparing 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.

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 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 from the beginning.

Let’s take the example of a banking application to understand the priority and severity of combinations better.

1. High Severity and High Priority

The banking application has a login page where the user is authenticated. The 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.

For example, the ‘Login’ button on the login form is not-clickable. After filling in the login details, the user cannot click the ‘Login’ button or login. 

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 log in, then what is the use of such an application? Users will avoid such applications, and businesses will be impacted. Such defects are a High priority and must be fixed as soon as possible.

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

The most common place for these high-severity and high-priority bugs is the critical user path – a path 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 can easily automate the critical user path. Testsigma is one such tool that has made it 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 does look good, key buttons are not displayed properly, functionality works, but the user experience is not good or even bad. This low severity but high priority affects user experience.

It is important to test applications across browsers and OS to catch these bugs. To catch these bugs automatically and quickly before a customer sees them, automate them via a tool that supports extensive cross-browser testing.

To save time and manual testing effort – you need a tool to 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 run them on many browsers and devices. Thus, while you waste no time in automating the test cases, the execution can be set up without any hassles. Also, the tests are executed in parallel to save your precious time.

Let us go through a specific example – On the user home page after login, the banking application shows all the options of – Deposits, Transfer, Account Summary, etc. In our example, ‘Transfer’ is misspelled as ‘Transfer’. This error does not affect the application’s functionality because the user can 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. Still, 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 the mobile testing was automated.

3. High Severity vs. Low Priority

For example, few actual users are still using the older IE versions like IE8. In 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, and this makes the priority Low because this fix can wait.

It is essential to execute test cases on old browser versions to catch such bugs before the customer catches them. 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 are required!

4. Low Severity vs. Low Priority

The ‘Help’ section of the banking website has a subsection whose theme does not match 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 proper priority and severity is essential. In the testing process, a common reference must be used to classify these bugs. Test Cases/Test Manager tools are the correct reference to type bugs correctly. If the test cases(both manual and automated) are marked with proper severity in the beginning, it will help the testers rank the bugs correctly while testing.

If both manual and automatic processes are in place, in many cases, automated tests are not appropriately marked. When there is a failure, the one executing and analyzing the results may not have full context and end up filing a bug with the wrong priority and severity. 

It is important to mark these correct at the Test Cases level for both Manual and Automated tests.Testsigma is a test automation platform with integrated Test Management for both Manual and Automated testing; add priority to your test cases in Testsigma in a jiffy. Moreover, you can use Testsigma for Manual Testing, Automated Cross-Browser Testing, Automated Regression Testing, Automated Web Application Testing, Automated Mobile App Testing, etc.

FAQ Questions:

Who Defines Severity and Priority?

The manager or the client defines the priority of defects in cooperation with the project goals and needs, the commercial values, and the QA engineer determines the severity levels of the functionality problems

What is the Difference Between Severity and Priority with Respect to a Bug?

Whether or not a bug has a significant impact, the bug severity is concerned with the product and how far this damage extends. In contrast, bug priority refers to the order in which bugs should be fixed depending on their impact on the system and other variables.

What are the 5 Levels of Severity?

There are 4 levels of severity where level 1 being the top priority

• Level 1 – System Down/Critical Impact Complete system failure.
• Level 2 – Significant impact/severe service downgrade
• Level 3 -Minor impact/Most of the system is operational.
• Level 4 – Informative/Low Impact.
• Level 5- Cosmetic

Frequently Asked Questions

What is Severity and Priority with Examples?

Severity and priority are terms used to classify and prioritise issues in software testing and bug tracking. Each phrase is defined below, with examples: Severity: The influence or significance of a fault on the functionality or usability of the software is referred to as its severity. It assesses how much the fault impacts the system’s planned behaviour. The severity levels are typically classified as high, medium, or low. Examples: High severity: A critical flaw that causes the software to crash or results in data loss. Medium severity: A flaw that affects critical functionalities but does not result in system failure. Low severity: A tiny flaw that has little influence on the functionality or usefulness of the software. Priority: The order in which faults should be addressed and remedied is referred to as priority. It determines the importance and urgency of correcting a defect. Priority levels are commonly classified as high, medium, or low.

Examples:

High priority: A problem that requires immediate attention and should be corrected before other flaws owing to the system’s or critical functionality’s considerable impact.

Medium priority: A fault that has to be fixed but may wait until high priority issues have been rectified.

Low priority: A fault that has a minor impact on system functionality and can be postponed to a later stage or future release.

What is Defect Priority vs Severity?

In software testing, defect priority and severity are two distinct but related concepts:

Defect priority: The order in which defects should be addressed and rectified is determined by their importance and urgency. It assists project managers and developers in successfully allocating resources. Priority is usually determined by criteria such as business effect, user requirements, project timelines, and customer needs.

Defect severity: The impact or seriousness of a defect on the functionality or usability of software is measured by defect severity. It describes how far the fault deviates from expected behaviour. The severity of a problem is determined primarily by its technical element and is typically assigned by testers or technical specialists.

Suggested Reading :

Techniques To Prevent Software Bugs

How to Write a Good Bug Report? Some Tips

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.