Bug Severity vs Priority in Testing
Shreya Bose, Technical Content Writer at BrowserStack - June 2, 2020
Bug severity and bug priority are two commonly used terms in software testing. However, they are often used interchangeably, which is incorrect. In this article, we will discuss each of them in detail and explain the difference between the two.
What is Bug Severity?
Bug severity is the measure of 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 occurs frequently 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 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 successfully planning a software development life cycle.
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 with multiple flaws in some legacy browsers. The logo does not load, text scrambles, images are too pixellated. 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 Firefox, 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 details of the product being offered.
Since key functions are clearly being adversely affected, bug severity is high. Since the broken functions are blocking a key phase of the user journey (actually buying the product), 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 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.
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.
The role of 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.
The best way to detect all bugs is to run software through real devices and browsers. When it comes to 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 cloud-based testing service that provides real device browsers and operating systems. BrowserStack offers 2000+ real browsers and devices for manual and automated testing. Users can sign up, log in, choose desired device-browser-OS combinations and start testing.
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 it’s users at any given time.