Bridging the Gap of Bug Severity vs Priority

No matter how hard developers try, there will always be software bugs. It’s unfortunate, but, sadly, nearly impossible to eliminate. Understanding how impactful they are to your team and your software is a huge part of your bug triage process. But how do you know what’s important to each of those parties?

Bug severity vs. priority is often mistaken for the same process, and while they share some overlap, they aren’t identical twins by any means. When you take the time to separate concerns based on bug priority and severity, you’ll have a much clearer picture of the overall quality of your software.

Bug Severity Statuses

When it comes to bugs, not all are equal. From harmless little CSS hiccups that make your images too far to the left to completely system-breaking issues, there’s a broad spectrum for defects. In most cases, bugs will cause interruptions to the basic functionality somehow, though the severity of that impact makes them dangerous.

Most dev teams will probably follow something similar to this for bug severity:

• Minor Severity - These are a little serious, they might slightly impact functionality or cause hiccups. However, these bugs aren’t impactful enough to disrupt critical parts of the application. Examples include:

  • Typos and grammatical errors.

  • Cosmetic issues that don’t affect functionality.

• Moderate Severity - When bugs start to cause problems with regular operations, they’ll end up in this category. These bugs may interrupt the software or cause delays, but they aren’t disruptive enough to halt functionality. Examples include:

  • UI inconsistencies.

  • Performance degradation or delays.

  • Incorrect data validation.

• Major Severity - If a bug or a defect completely halts the application, it’s probably going to fall under this category. They greatly impact functionality and need to be prioritized so it can be resolved. Some examples are:

  • Crashing and freezing.

  • Data corruption.

  • Exploitable security vulnerabilities.

• Critical Severity - The worst of the worst, these bugs bring your application to a complete halt, or worse, total failure. They are the top level of concerns and need to be resolved quickly, or there could be disastrous outcomes.

  • Complete data loss.

  • Total system failure.

  • Security breaches.

Bug Prioritization

On the other side of the spectrum, there’s bug prioritization. Often confused to be the same as bug severity, there are quite a few differences between the two.

Unlike severity, here you’ll be organizing how quickly a bug needs to be fixed instead of only worrying about what the effects of that bug are. A great example in action is a Firefox tooltip bug that was fixed after 22 years after being left at a low priority for so long.

However, like severity, different levels can be assigned during defect triage:

• Deferred - These are identified but aren’t impactful enough for an immediate fix. They’re the lowest in priority and usually have minimal impact overall.

• Low Priority - Bugs that impact software in slight ways will end up here, generally if they’re only minimal issues. These are usually fixed around the end of a development cycle left for the final stretch once everything else is resolved.

• Medium Priority - These bugs have a noticeable impact on software performance but aren’t serious enough to be fixed immediately. They’re probably inconvenient issues, but nothing that makes software unusable.

• High Priority - Anything found during bug triage that significantly impacts software performance will be here. These issues must be addressed immediately, as they can greatly detriment to your users and your software.

• Critical Priority - The absolutely most severe issues will be marked as “Critical”. Bugs like these often are the ones that lead to software crashes, huge security vulnerabilities, or anything that can stop your software dead in its tracks.

What affects Bug Priority?

There are a ton of factors that can affect the priority of a bug during defect triage. When your teams are prioritizing bugs, they should consider the following:

• Business Impact. Does this bug affect the business in any way? If so, how impactful would it be to release into the wild? Typos that advertise the wrong thing can be a higher priority over a button on a rarely-used page that doesn’t work.

• User Impact. How will our end-users be affected by this bug? Is there a chance they’ll lose access to our software or lose something such as data or money? This type of impact can be a considerable factor in priority.

• Project Deadlines. Does your team have the time to fix these issues? You’re most likely working within an Agile methodology, but do you have enough time in the current sprint to resolve the problem? Or does this need to be brought up to stakeholders and delayed for a future release?

• Customer Requirements. How would the customer feel about this bug? Not all software goes straight to everyday users. You may be working with a client with incredibly high standards, making some bugs more important than others.

• Regulatory Compliance. Depending on your industry, governmental regulations can make or break how critical some bugs are. This is especially true regarding data privacy, making any security vulnerabilities incredibly important.

Relationship Between Bug Severity vs Priority

As you can tell, there’s quite a bit of overlap between bug severity and priority. But for all their similarities, they are still two different parts of the defect triage process. They both interact with each other in different ways, with the most obvious one being how you look at a bug. Bug severity lays out how much of an impact that bug makes, while bug priority reflects how critical that bug is within the full scope of the project beyond software.

That makes it a tricky part of the bug triage process. Team members need to understand these concepts and communicate between QA, dev, and DevOps teams to agree. Without good communication, it’s very likely that significant issues fall between the cracks or severe vulnerabilities never get patched.

For example, let’s say there’s a bug with Low Priority, High Severity. This might have made a huge impact on the software's functionality, but it was discovered too late into the sprint to be fixed. It might have to be pushed back into the next release, as it’s not a top priority.

On the other hand, if we have a defect that’s High Priority or Low Severity, it could be a completely different story. Bugs like visual defects that can affect how your software looks and feels may be prioritized first, as they can ruin the user experience and drive them away.

Bug Tracking and Management

It’s just as important to track and manage your bugs throughout the defect triage process as balancing bug severity vs priority. This means you should have your entire bug triage process set up in a way that works for your whole team. Let’s break it down into a few digestible chunks.

First, you should already have a way to track all the bugs your teams find in development. There are many different bug-tracking tools and systems, or you can use the already-existing features within Jira and GitHub. Once that’s set up, you’ll want to work with your team on assigning both severity and priority and communicating with everyone involved so they can come to an agreement.

After bugs have been tracked and categorized adequately by severity and priority, teams should be working on getting them resolved. As development continues, bugs will need to be updated and re-evaluated to account for the changes within the software and the timeframe until the next release. Bugs also need to be monitored to ensure that as bugs get fixed, teams pick up new ones to resolve based on priority so nothing gets left behind.

Find and Focus on What Matters with Launchable

Testing will throw all kinds of data at you no matter how you slice it. Even with an efficient team, there’s still an overload of information at your disposal, and it’s not easy to sift through. We know exactly how frustrating that can be, and that’s why we’ve launched our Intelligent Test Failure Diagnostics — why waste time and energy manually sifting through testing data when there’s automation?

Spot what went wrong and track it. Launchable scours through your error logs and gives you a summary of any failures and why they happened. Then, we store it and group it with similar issues, keeping you in the loop without busting out a pen and paper.

Get a birds-eye view of all the issues within your software. Thanks to our test suite reports, we can show you the entire history of that issue so you’ll know if it’s a recurring or a one-time problem. Plus, we give you detailed information into your test cases that even links back to PRs and builds so you have all the context you need to see what went wrong.

Test smarter for faster releases. Use Predictive Test Selection in your existing development pipeline and unlock the ability to release faster by intelligently running a smaller set of tests that are most likely to find failures first. With data-driven testing you can quickly find and verify test issues, ensuring every test that is run counts.