Bug Severity vs Priority in Testing
By Shreya Bose, Community Contributor - September 3, 2022
‘Bugs’ is the buzzword in the Software Testing landscape. With every release cycle, the whole idea behind testing is to find bugs in software before it reaches the users. Several types of testing, test reporting, and bug tracking are done to ensure that the bugs found during software development are rectified to deliver high-quality, bug-free applications.
In this entire process of finding and rectifying bugs, Bug Severity and Bug Priority are two commonly used terms. However, they are often used interchangeably, which is incorrect. This article discusses each of them in detail and explains the difference between the two using examples.
What is Bug Severity?
Bug severity is the measure of the impact a defect (or bug) can have on the development or functioning of an application feature when it is being used. It depends on the effect of the bug on the system. Depending on how much of a threat the bug can pose to the software, bug severity can be divided into multiple levels:
- Low: Bug won’t result in any noticeable breakdown of the system
- Minor: Results in some unexpected or undesired behavior, but not enough to disrupt system function
- Major: Bug capable of collapsing large parts of the system
- Critical: Bug capable of triggering complete system shutdown
Usually, QA engineers are the ones to determine the level of bug severity.
How to determine Bug Severity?
- Identify how frequently the bug can occur. Even if the bug itself is minor, it can be problematic if it frequently occurs in the code. In this case, the minor defect can majorly disrupt the end-user experience.
- Once the defect has been isolated and identified, it can be examined to evaluate its severity.
What is Bug Priority?
Bug priority refers to how urgently a bug needs to be fixed and eliminated from the website or app in question. Basically, it’s a measure of how the bug should be prioritized in the debugging hierarchy. Correctly assigning bug priority is integral to planning a software development life cycle successfully.
Levels of bug priority:
- Low: Bug can be fixed at a later date. Other, more serious bugs take priority
- Medium: Bug can be fixed in the normal course of development and testing.
- High: Bug must be resolved at the earliest as it affects the system adversely and renders it unusable until it is resolved.
Testers can determine bug priority with the same two steps described earlier to determine bug severity.
Bug Severity vs Priority
|Bug Severity||Bug Priority|
|Refers to a measure of the impact that a bug can has on software functioning||Refers to the order in which developers have to fix bugs|
|Driven by performance of software function||Driven by business value and time to release|
|Subjective value that is likely to change over the course of development or with regard to resolution of other bugs||Objective value that is not very likely to change significantly in a software development process|
|High severity and low priority status means that the bug can cause significant damage, but can be fixed at a later date||High priority and low severity status means that the bug must be fixed immediately but it does not affect the software too adversely|
Example of High Severity and Low Priority
A website renders multiple flaws in some legacy browsers. The logo does not load, text scrambles and images are too pixelated. Since this is a disruption to product functionality as well as user experience, bug severity is high. However, since the problem only occurs with legacy browsers, it won’t be affecting a large number of users. Hence, bug priority is low.
Example of High Severity and High Priority
A website is being tested on Chrome and works perfectly. But when switched to Edge, the pricing page shows major flaws. Buy buttons for purchasing plans have disappeared, and so has the text that outlines the prices and corresponding features included in each plan. In this case, anyone using Firefox cannot buy the product or even know the details of the product being offered. Hence cross browser compatibility beyond Chrome is important and should be considered during software testing.
Since key functions are clearly being adversely affected, bug severity is high. In such cases, the broken functions block a key phase of the user journey (actually buying the product). Hence, bug priority is high.
Example of Low Severity and High Priority
While testing the functionality of a website, it is seen that buttons are slightly out of place when the site is run on Chrome. They can still be clicked easily and do what they are meant to. This means that functionality is not affected hence bug severity is low. However, since out-of-place buttons don’t exactly make for a pleasurable visual representation and badly designed websites actively turn off users, bug priority is high. The issue needs to be fixed as fast as possible.
Read More: Understanding Visual bugs
Example of Low Severity and Low Priority
While testing the website, some of the text is found to have typos, and the font and color do not match the color and font of the website’s primary design. Now, this is a bug for sure, but it is certainly not a real problem in functionality. Hence, bug severity is low. Similarly, it does not need to be fixed immediately, and hence bug priority is low.
Debugging using Real Devices
Now, it is not possible to assign bug priority and bug severity without knowing the exact nature of the bug. Also, it’s important to know how frequently a bug occurs and how it affects the software. However, no matter which level of Bug Severity or Bug Priority your bug has, detecting and debugging it using real devices is the most effective way.
The best way to detect all bugs is to run software through real devices and browsers. When it comes to a website, ensure that it is under the purview of both manual testing and automation testing. Automation Selenium testing should supplement manual tests so that testers do not miss any bugs in the Quality Assurance process.
In the absence of an in-house device lab, the best option is to opt for a read device cloud that provides access to real devices, browsers, and operating systems. BrowserStack offers 3000+ real browsers and devices for manual and automated testing. Users can sign up for free and choose desired device-browser-OS out of 3000+ combinations and start testing.
With features like DevTools, Automated Screenshots, Text, and Video Logs, debugging has become easy.
The same applies to apps. BrowserStack also offers real devices for mobile app testing and automated app testing. Simply upload the app to the required device-OS combination and check to see how it functions in the real world.
Additionally, BrowserStack offers a wide range of debugging tools that make it easy to share and resolve bugs. This includes text and video logs to identify exactly where and why a test failed, thus letting testers zero in on what issue to work on.
By running testing in real user conditions, testers can find the number of bugs, their nature, and how often they occur. Then, they can accurately assign bug severity and priority in testing. This, in turn, helps to run debugging activities in the right order so that the software can provide the best possible service to its users at any given time.