How to Start the Bug Triage Process

You may have heard of a bug triage process. It’s when you go through a list of bugs and prioritize which ones will get fixed now, later, or possibly never. While in an ideal world, we would have time to fix every problem, that’s not the case for modern software development. You only have so much time between releases, and much of that time is spent working on new features and making the application compatible with the latest technology.

Yet bug fixes are expected as well, which is why the bug triage process is so helpful. It lets you discover which bugs are the most oppressive and narrows your focus to just those. In this article, we will review some of the basics behind the process and discuss how we make it easier for .NET and Java developers with Loupe Server.

How Do I Start the Bug Triage Process?

You want to start by collecting a complete list of bugs. If you don’t know the bugs in your application, how can you effectively triage them?

If you have any user reports or documented complaints, that is a great place to start. If an issue was important enough that a person or multiple people bothered to reach out, that’s a pretty good indicator that resolving the issue will improve some people’s experience.

But not every organization will have a wealth of user feedback to use. In that case, you can start by looking through your log data. Even if you had user feedback, you would likely end up in the logs anyway to get the technical details on their problems. This means either combing through log files by hand or looking at your data in a centralized logging system if you have one (it will be much easier with a centralized logging system). Either way, when first looking at the log data, try to do the following:

• Determine if the error actually represents a bug. You will sometimes get errors for expected behavior. For instance, someone misspells their username. You may get a database error for the related query because it doesn’t recognize the username. This is normal. Your DB is not going to account for a username that doesn’t exist. It’s a user error/operational issue, not a bug. You can almost certainly remove it from the triage process.

• Determine if the error is in your current release. Not everyone is going to update their software every release. So any issue that persists in a previous release but is fixed in a more recent release, you can safely ignore.

• Potentially combine similar errors. If two error logs look very similar, take a closer look. You may want to combine very similar errors, as the same underlying root problem may be responsible for both. By combining the bugs, you avoid unintentionally assigning the same problem to multiple people. If that turns out the bugs do not have the same underlying problem, you can separate the bugs after the fact.

The main idea is to reduce the number of items you need to run through the complete bug triage process. Cutting out obvious non-issues, older releases, and combining bugs that stem from the same underlying problem help do that. Once you finish this process, you can start to rate the bugs by importance.

Which Bugs Do I Prioritize?

When judging which bugs to prioritize fixing, there are four questions you want to ask:

1. What is the severity of the bug? How large of an interruption is it for an end user? A quick way to get a decent idea is to find the logging level for the problem. In most cases, a warning will be less disruptive than an error which is less disruptive than a fatal error.

2. How frequently does the bug occur? If I have two bugs that result in fatal errors, the one that occurred seven times is likely a more significant problem than the one that only happens once.

3. How widespread is the bug? How many users have encountered the bug while using the application? If I have two bugs that have occurred seven times, but one occurred for only one user, and the other occurred for five users, I’ll likely want to solve the bug that happened for the five users to improve more people’s experience.

4. When did the bug first appear? If I have two bugs equal in severity, but one has been around for five years, and the other bug was introduced three months ago, I will likely prioritize the bug that occurred three months ago. When in doubt, prioritize the most recent bug. It may seem counter-intuitive, but if a bug has been around for five years and no one has bothered to fix it, that likely means it’s not a massive problem.

These questions will help you understand how important it is to resolve the bug, but there is no exact science. What these questions ignore is the content of the bug. When ultimately deciding which bugs you want to prioritize, the content of the bug matters. For example, if a bug represents possible security issues, you may want to prioritize it highly despite the answers to these questions.

How is Bug Triage Done in Loupe?

In Loupe, the bug triage process primarily occurs on the “Event Review” page for your application.

Note that you can organize the events by three categories:

1. Most Recent

2. Most Widespread

3. Most Frequent

We know that these are the major factors that most developers will use to prioritize their bugs. By allowing users to organize all their events by these factors, they can quickly see any outliers in each category. Additionally, every event includes info on when it was last seen, the last user to see it, the most recent version the event appeared in, the number of occurrences, users, and more. The idea is to provide as much information as possible to help developers better answer which bugs are critical to fix and which ones can wait.

You will notice we include a caption as well. The caption is a snippet of the “content” of the error that caused the event. You can click on each error and look at the event in full detail.

Any event that isn’t actually a bug or isn’t necessary to fix can be removed from the list by “suppressing” or “ignoring” it. When you suppress an item, it’s removed from the event list, and no other instance of that specific event will ever be added again. When you “ignore” an event, it’s removed from the list but will come back the next time it happens.

Any events that are bugs you want to prioritize, you can create an “issue” for. An issue formally assigns the problem to a member or a group on your team. Additionally, you can add multiple errors to the same issue if you deem them similar enough.

You can watch the review list in action in the above Loupe Demo (Loupe’s look has changed slightly since then, but the core function remains the same). Or you can try it out for yourself if you are a .NET or Java developer looking to clean up your bug triage process. Give our free demo a try in the link below.

Try Out Loupe Server