Bug Severity vs Priority, or How to Manage Defect Fixing

Bug severity and bug priority are two closely related notions. Still, these are two different terms describing slightly different sides of a defect. It is essential to distinguish severity and priority for everyone engaged in the development process. A clear understanding of the difference makes it easier to find the best answer to the question “What to fix first?” that can cause tension between QA engineers, developers, and stakeholders. Hopefully, this article will explain the basics and help to clear the air.

What Is Bug Severity?

Bug severity is the extent of the impact a particular defect has on the software under 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 an error makes it impossible to proceed with using or testing the software. For instance, it shuts an application down.
• Critical (S2). It is an incorrect functioning of a particular area of business-critical software functionality, like unsuccessful installation or failure of its main features.
• Major (S3). An error has a significant impact on an application, but other inputs and parts of the system remain functional, so you can still use it.
• Minor (S4). A defect is confusing or causes undesirable behavior but doesn’t affect user experience significantly. Many UI bugs belong here.
• Low/Trivial (S5). A bug doesn’t affect the functionality or isn’t evident. It can be a problem with third-party apps, grammar or spelling mistakes, etc.

What Is Bug Priority?

Bug priority is a way to decide in what order the defects will be fixed. The higher the priority is, the sooner a development team is going to look into the problem. Very often, bug priority is determined by its severity. Well, it is reasonable to start fixing with blockers rather than minor defects.

Levels of Bug Priority

• High (P1). The defect is critical to the product and has to be resolved as soon as possible.
• Medium (P2). The error doesn’t require urgent resolution and can be fixed during the usual course of activities – for example, during the next sprint.
• Low (P3). The bug isn’t serious, so it can be resolved 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 impact on a user and business performance, it is essential to fix it as soon as possible. For instance, if an installation fails or a user cannot register/sign in, a team should fix these issues immediately.
• Upcoming release. If bugs are troubling but don’t affect the core functionality, a team doesn’t need to go with a hotfix. For example, a broken layout is confusing, but it doesn’t interfere with actual functionality. It is okay to add this fix to a pool of the tasks for the nearest update.
• Later sprints. If problems aren’t severe and there’s no pressure from a user’s or business side, the bugs go to a backlog and are resolved sometime during the upcoming sprints. It is a common scenario of dealing with typos and minor compatibility issues.

Do We Need Both Severity and Priority?

Basically, the severity and priority both describe the level of criticality of a defect. Seemingly, the priority should entirely depend on the severity. It sounds reasonable to determine the order of fixing defects based on their criticality. However, it is more complicated.

Severity reflects a possible impact of a defect on a user. Therefore, a QA team assigns severity to each defect. Since QA specialists study a system to evaluate it from a user’s viewpoint, they can tell how bad it is broken.

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

So yes, we need both priority and severity. Though closely related, these two criteria aren’t always interdependent. Severity doesn’t necessarily determine priority. As a result, these terms are usually operated by different groups of specialists participating in software development.

How to Assign Bug Severity?

To determine the degree of severity of a defect, QA engineers identify how frequently it occurs and to what extent it influences the functionality. It is significant to consider both parameters.

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

How to Assign Bug Priority?

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

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

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

Different Severity and Priority Combinations

Here’s one more illustrative example of why we need both severity and priority. The combination of these two bug attributes can be different.

• A high severity with a high priority: a user cannot log in to the account. There’s no need for long explanations, right?
• A low severity with a low priority: design of a rarely visited section doesn’t match the recently updated website design. It often happens 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 affect functionality, but they can affect user’s perception of a brand and, thus, satisfaction rates and even revenue.
• A high severity with a low priority: layout doesn’t fully load in older versions of legacy browsers. Though the entire application is affected, if only a few users access the website via these browsers, fixing these issues will not be of high importance.

Bug Severity and Priority: The Friction

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

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

So the conflict comes from a human factor. When a team works towards a common goal, which is releasing the best product possible, everyone can become a little too excited. Transparent communication is what helps to avoid suchlike situations. Still, each specialist should understand the hierarchy of the development process and read the situation. In other words, just do your job well and know when it is reasonable to ask for clarifications.

To Sum Up

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