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. 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.
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. How widespread is the bug? How many users have encountered the bug while using the application?
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. 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.
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. Pro Tip: Ideally you'll budget enough time to get through everything, but if your list is too large to process in a single triage session, prioritize looking at Type-Bug-Regression i. Once you've triaged the most important issues, sanity check your team's load balance to make sure that you haven't overloaded anyone.
More Pro Tips Set aside a regular time and place to Triage. Give yourself enough time to handle your incoming stream of issues and make progress on or at least review your backlog. Though they are a little more burdensome to administer, they tend to be the most sustainable triage efforts, help prevent people from burning out, and ensure that the process doesn't break when people take a vacation. Wade into and clean-up your backlog. Make sure that things are properly categorized, especially as Available issues, so that they are discoverable.
Spend most of your time on issues opened in the last year. Most issues have a half-life. Issue reports are a static reflection of what was That is People will re-file and often duplicate important issues.
Once you have the categories identified, you can develop different routings, strategies, or resources to deal with each category. Typical sorting schemes include:. Response schemes include:. The IT department in one company was overloaded with work requests ranging from installing new software to updating virus definitions and fixing email connections.
On average, it was taking them more than six working days to respond to requests. Each day, the IT staff would sort requests submitted the previous day, except for Class 1 requests which were dealt with as soon as possible.
The staff would address remaining Class 1 problems first before moving on to Class 2, and then on to Class 3. Imagine walking into a bank or hotel and asking some customers to stand off to the side while others are moved to the front of the line. In these cases you will need to develop backup capacity. To calculate the mean, add all of the individual data points then divide that figure by the total number of data points.
Originally, it took the marketing department as long as two to three weeks to develop the needed information. They wanted their information within two or three days. The singular is "datum. But they often had two or three times that number waiting to be worked on. So they developed a system where all requests went into a buffer , an in-box of sorts; and then they used triage to determine which ones to work on next.
0コメント