Bug Severity vs Priority in Testing

Bug severity and bug priority are two similarly related notions. Still, these are two different terms describing slightly distinctive sides of a defect.

It is necessary to distinguish severity and priority for everyone involved in the development process. A clear perception of the difference makes it simpler to discover the best answer to the question “What to fix first?” that can cause stress between QA engineers, developers, and stakeholders.

Hopefully, this article will describe the basics and help to clear the air.

What Is Bug Severity?

Bug severity is the amount of impact a critical defect has on the software below the test. The higher effect this defect has on the overall functionality or performance, the higher the severity level is.

Levels of Bug Severity

• Blocker (S1). Such a bug makes it impossible to continue with using or testing the software. For example, it shuts an application down.
• Critical (S2). It is an inaccurate functioning of a particular section of business-critical software functionality, like failed installation or failure of its main features.
• Major (S3). An error has a significant influence on an application, but other inputs and components of the system remain functional, so you can still utilize it.
• Minor (S4). A defect is complex or causes undesirable behavior but doesn’t change user experience significantly. Various UI bugs belong here.
• Low/Trivial (S5). A bug doesn’t alter the functionality or isn’t visible. It can be a dilemma with third-party apps, grammar or spelling mistakes, etc.

What Is Bug Priority?

Bug priority is a way to determine in what order the defects will be repaired. The higher the priority is, the earlier a development team is going to look into the difficulty. Very often, bug priority is defined by its severity. Well, it is reasonable to begin fixing with blockers rather than minor defects.

Levels of Bug Priority

• High (P1). The defect is critical to the product and has to be fixed as soon as possible.
• Medium (P2). The error doesn’t need urgent resolution and can be repaired during the usual course of action– for example, through the next sprint.
• Low (P3). The bug isn’t severe, so it can be fixed after the critical defects are fixed or not fixed at all.

Based on these, we can also classify fixes per their timing:

• Hotfix. If a defect has a high influence on a user and business performance, it is necessary to repair it as soon as possible. For example, if an installation fails or a user cannot register/sign in, a team should repair these issues immediately.
• Upcoming release. If bugs are troubling but don’t alter the core functionality, a team doesn’t require to go with a hotfix. For instance, a broken layout is complex, but it doesn’t interfere with original functionality. It is okay to add this fix to a pool of the jobs for the nearest update.
• Later sprints. If problems aren’t difficult and there’s no obligation from a user’s or business side, the bugs go to a backlog and are fixed sometime during the upcoming sprints. It is a simple scenario of dealing with typos and minor compatibility problems.

Do We Need Both Severity and Priority?

Basically, the severity and priority both define the level of criticality of a defect. Apparently, the priority should completely depend on the severity. It sounds reasonable to define the order of fixing defects depending on their criticality. However, it is more complex. 

Severity displays a possible impact of a defect on a user. Hence, a QA team assigns severity to each defect. Since QA specialists analyze a system to evaluate it from a user’s perspective, they can say how bad it is broken.

Priority establishes the order in which developers will repair bugs. It is up to a person in charge – Project Manager, Product Owner, Business Analyst, etc. –  to conclude this order. Defect severity is one of the measures used for defining the priority, but not always the defining one. Stakeholders decide on the priority with a greater picture in mind. They always have to acknowledge business implications.

So yes, we require both priority and severity. Though closely related, these two measures aren’t always interdependent. Severity doesn’t significantly determine priority. As a result, these terms are usually run by various groups of specialists participating in software development.

How to Assign Bug Severity?

To define the degree of severity of a defect, QA engineers recognize how frequently it occurs and to what extent it affects the functionality. It is important to consider both parameters. 

Let’s say we’ve got the wrong size of specification icons on all product pages and overlapping buttons on two popular products. These are both instances of the broken layout. However, the icons only appear displeasing, while a problem with buttons disables buying functionality. The nature of these defects is similar, but their levels of severity differ.

How to Assign Bug Priority?

If you a) have to decide on bug priority but aren’t certain how to do it accurately or b) are a QA specialist exasperated by the way the discovered bugs have been prioritized, here are a few questions that will help you understand this process completely:

• How many users does a bug affect?
• What functionality is affected?
• On what devices and OS does a bug happen?
• Is there a reduction in activity because of this defect?
• Does the company begin losing money because of it?
• Is users’ trust or a company’s image transformed?
• Does this software issue carry legal implications?

As you can observe, there’s more to this issue than severity. It is necessary to pay attention to business data, too.

Different Severity and Priority Combinations

Here are one more illustrative example of why we require both severity and priority. The combination of these two bug characteristics can be different. 

• A high severity with a high priority: a user cannot log in to the account. There’s no requirement for long explanations, right?
• A low severity with a low priority: design of an unusually visited section doesn’t match the newly updated website design. It often occurs after rebranding, and some pages can wait for updates for months.
• A low severity with a high priority: broken layout or typos on the top-visited pages. These things don’t alter functionality, but they can influence user’s perception of a brand and, thus, satisfaction rates and even revenue.
• A high severity with a low priority: layout doesn’t completely load in older versions of legacy browsers. Though the complete application is affected, if only a few users access the website through these browsers, repairing these issues will not be of high importance.

Bug Severity and Priority: The Friction

So what actually generates tension and conflicts? A development team might be confused when there’s a mismatch in expectations about severity and priority. In some instances, each party is certain they have more reasons to advise on the priority of a particular issue. However, it is only for stakeholders to choose. 

If a QA engineer or a developer understands the priority should be different, they should address an issue calmly. It would be excellent if a person in charge of the decision should share their reasons for specifying a particular priority. And vice versa, if a stakeholder doesn’t explain why a particular issue has the specified severity, they should ask for clarification. 

So the conflict arises from a human factor. When a team operates towards a common goal, which is delivering the best product possible, everyone can become a little too excited. Transparent communication is what helps to bypass suchlike circumstances. Still, each specialist should know the hierarchy of the development process and understand the situation. In other terms, just do your job well and know when it is feasible to ask for explanations.

Also Read: 8 Important Success Factors Of QA Project

To Sum Up

Severity and priority are parameters managed by different teams. However, severity is one of the key factors for prioritizing a defect. A project leader is the one to examine both and make a decision. The best you can do is identify the difference between bug severity and priority and don’t apply these terms interchangeably. Another section of advice would be to pay attention to the roles and responsibilities every member of the team has. QA engineers should back up the development with their expertise in product quality research, while analysts and managers ensure that every decision is based on business purposes and with a bigger picture in mind.

At TestUnity, we strive for the highest quality in every project, and our professional QA specialists are ready to ensure it. Contact us if you’re looking for a dedicated team to enhance your product’s quality.

TestUnity

Testunity is a SaaS-based technology platform driven by a vast community of testers & QAs spread around the world, powered by technology & testing experts to create the dedicated testing hub. Which is capable of providing almost all kind of testing services for almost all the platforms exists in software word.