How to prioritize bugs?
Bug prioritization can be difficult - there are always more bugs to fix than the time and resources available. Of course, we want them fixed as soon as possible, but how can we decide which ones we should select right away and which can wait?
Let's focus on organizing the issues into categories to help us prioritize them.
Severity and priority
Severity measures how serious the bug is in terms of how it affects users. Though severity often affects priority, it doesn’t necessarily have anything to do with priority. For example, a bug that causes data to be lost might be considered more severe than one that simply displays an error message.
Priority refers to how critical the bug is to the overall functionality of the software and the order in which bugs should be fixed.
User experience and business value
Some features have more value than others; they sell the product and are used the most. Obviously, bugs found while testing the key scenarios will have higher priority.
Here are some examples:
- Bugs in the login/register functionality will be more important than changing a username or deleting an account.
- A typo in the main menu is always visible to users and will have a higher priority than an error message for an incorrect value.
The general user experience helps a lot, but we need to learn this particular product functionalities to gain user experience.
Firstly, prepare a list of all the essential features in the product to set their business value. It's also worth watching for errors affecting the most active and valuable users if there is such a case in the project.
The bugs occurring the most need to be fixed first - they’re probably the ones affecting most people in the most common situations. Frequency alone is not enough, though. There are annoying bugs, but if they don’t prevent users from using the product - find and document a workaround. That's when they’re less important than bugs that crash the whole application.
Some issue types will always have a massive impact on the product. Here's an example schema for prioritizing particular issue types. Of course, every product and user's needs are different, and this guideline should be adjusted to your project, but it's a great starting point:
- Main functionality missing or not working
- API responses for most important endpoints are invalid
- Key use cases fail, and there is no workaround
- Further testing is blocked
- Undercharging/overcharging customers
- Crash errors
- Critical business value bugs
- Data loss
- Security issues
- Minor functionality is not working
- API responses for less important endpoints are invalid
- Key use cases fail, but there is an easy workaround
- Redirecting issues
- Missing elements, buttons
- Rarely used functionality is not working
- Validation fails
- Errors in console
- UI bug visible to most users
- Minor loss to business
- Incorrect color, font, size of logos
- Typos in text
- UI bugs most users won’t notice
- No loss to business
- Typos in error messages
Remember that one prioritization criterion is not enough - you need to look at found issues from different perspectives. Bugs are inevitable in software development, but you're not alone!
Whenever you have doubts, don't hesitate to ask other team members for help - members of business and dev teams can help you understand their views, and it will be easier for you to do this task.