Reporting bugs is an essential part of QA testing. But developers can only address so many bugs at once, so how do you prioritize bug fixes? Every team does things a little differently. Some teams have product or project managers do it. Other teams have QA estimate priorities when reporting bugs. Either way, a good QA tester should be savvy when it comes to estimating the severity and priority of bug tickets.

Not Sure How to Prioritize Bug Fixes? Consider These Factors:

How serious is the bug?

There’s a big difference between a mobile app crashing every time a user logs in vs. being a little slow to load the profile section. Is the bug something that will leave users angry? Will they be unable to use a certain page/screen or section? Or does it have a minor impact with easy workarounds? The bug’s affect on user experience will play into prioritization.

How often does the bug occur?

Is a user unable to save changes within the site 100% of the time? Or is it only happening to 1 out of 1,000 users? QA cares about all users, but the frequency of a bug changes the severity.

What devices or browsers is the bug happening on?

Is it affecting all iPhones on the most recent version of iOS? Or only iPhone 5s on iOS 9? Is it on all browsers, or just Internet Explorer 10? This ties into frequency. Much like the above issue, it will impact priority. Learn more in our guide to cross browser testing.

It’s also helpful to have market share data for different devices/OS versions/browsers. This is especially true for your specific user base. Having that level of data lets you determine how relevant the bug is. If it’s a really uncommon/old version, the company might even consider ending formal support for it, removing the need to fix the bug.

Is the bug causing users to abandon the product and/or leave bad reviews?

This is another area where a little research comes in handy. Check out the company mentions on social media and App/Play Store reviews. If you have access, review the analytics on account deletion. Are users ranting about the bug on Twitter? Is the App Store listing getting flooded with one-star complaints? Do you see an uptick in users deleting their account since the bug was introduced? These can have a significant impact on your bottom line. As a result, they should be heavily considered when prioritizing the bug fix.

(If you’re experience problematic app reviews, you can check out our how-to guide on improving app ratings.)

How long has the bug been happening?

Even the best Engineering team can’t stop 100% of issues from making it to production 100% of the time. Check older builds or versions to see if the bug might be in those as well. If it’s been there for months already and hasn’t prompted many noticeable complaints from users, it’s probably less urgent to fix.

Software Testing Bug Categories

While each Agile QA process might have slight differences, this is a common list of severity options:

Blocker. Also known as a showstopper, a “blocker” bug is considered a must-fix before the next release can go out.

Critical. A critical bug is extremely important to fix, and should be included in the sprint if at all possible.

High. A “high” severity bug has a significant impact on users or branding, and should be addressed soon.

Medium. A “medium” severity bug isn’t ideal, but may have a workaround. It should be fixed at some point, but not necessarily in the current sprint.

Low. A bug marked as “low” is not urgent. In fact, it may not even end up being fixed at all. These will typically be sitting in the backlog for a while.

Other Aspects to Consider

While we’ve covered many common factors for deciding how to prioritize bug fixes, there are a few others that come into play.

What new features are coming out in the same sprint?

If there’s a big feature with a release date that’s been planned and promoted for months, delaying the feature could have negative impacts for stakeholders. Unless the bug is absolutely critical, it might have to wait until after the feature is released.

Is the relevant section of the app or site being highlighted or called out in any special way?

For example, you might have a call-to-action banner on the home screen or page directing users to an area that’s now broken. If this is the case, the priority might get bumped up. The team might also decide to change the banner instead.

Hopefully your mobile app or website won’t have too many bugs. But as you do find them, now you know how to prioritize bug fixes. Not only does sprint planning become more efficient when you use the above risk-based approach, but you’ll also have a strategic approach in place to care of your customers.

Need Help Prioritizing Bug Fixes?

We do Agile consulting and QA testing services. Let’s talk!