Hi there, I’m a product designer at a company called Global App Testing. I’m doing some research to better understand folks triaging processes. Do you often need to triage long lists of issues/bugs reported by a third party or someone other than yourself? How do you approach this process?
What tool do you use for triaging?
What is the first thing you do/look for?
What do you do if you identify several issues that have the the same root cause?
What are the main pain points you experience during the triaging process?
If you had a magic wand, how would you make the triaging process better?
I used to triage new tickets daily in one of my previous roles, a few of us would go over issues reported by the support teams, and we would take a brief look into the issues and check if it is an already known issue, a user error, lacking info (and return it to the reporter for more details) or if it’s valid to assign it to an appropriate team.
We didn’t use anything fancy just an assortment of custom labels in Jira to categorize triaged issues. If tickets were similar or had the same root cause we would like them together using different relationships (caused by, causes, related to, etc.) - these can be customized to suit your needs too.
The biggest issue was little respect for the agreed-upon process by the support folks - who were a part of an external company. Everyone agreed what is the minimum info needed on the ticket - such as clear steps to reproduce, screenshots, or recordings when applicable. And to be honest it was pretty frustrating returning tickets over and over again for the same reasons.
For the magic wand part, I’d use it to cast spells that would result in people following the process they agreed to, to increase the domain knowledge of users, and summon more tech-savvy subject matter experts to the triage meeting!
Hi Mirza, thanks for your reply! This resonates a lot with what other folks I have spoken to about this have said.
The biggest issue was little respect for the agreed-upon process
That sounds very frustrating. A bad bug report seems like a waste of everyones time - both the person writing it as well as the person triaging it?
we would take a brief look into the issues and check if it is an already known issue
How would you check if it was an already known issue?
If you don’t mind me asking, I’m curious to learn more about the custom labels you would use in Jira. What are some examples of labels/categories you would use?
Yes, everyone wastes time if things go back and forth, one of the reasons for this is that the company where the support people came from was a huge company and most of the support folks didn’t stick around for long.
As for checking if the issue was already known or now, often we would just recognize things on the spot as a lot of the same issues were getting reported over and over again. We tried raising the issue with the upper management but that did us little good. Other than that a quick Jira search would often be enough to find a duplicate or a similar ticket - in this regard having a good system to categorize tickets would help, you know custom fields, sensible labels, and things like that.
After triaging we would add labels such as triaged, declined, and duplicate - for example, if an issue was a duplicate (meaning we already had an ongoing ticket for it) we would just link it as duplicate and add the description in the comment.
To sum it up, to really improve the triaging process you need to experiment and try out a lot of things to see if they will work, also convincing everyone involved to get on board will make things much easier.
I see how that must have beer very challenging with new people coming in all the time, needing to learn the bug reporting process, being new to the domain, and or course having no knowledge of previously reported bugs. Did your company/team have some kind of framework/strategy for what kind of bugs you wanted the support team to report vs. which type of bugs they don’t need to bother with? Or did you want them to report any type of defect they would find?
Learning through experimentation and getting everyone onboard with the same process - totally agree with this one!
The issue was that it was a big enterprise client with a lot of companies working for them as contractors, and support people were from one company and the triage team was from two other agencies - which made communication slow and pretty ineffective, they only times when things got done was when some C-level manager on the client side would get angry if the company was losing money and/or the customers were facing major issues
There was a pretty good initiative to fully document the onboarding process for new people arriving but it didn’t get management support, unfortunately. But at that time I realized it was time to look for greener pastures and moved to a new company withing a month.
I’ve just remembered Kim Knup’s excellent post on their experiment with a zero-bug policy. If not on your radar, it’s worth a read to spark ideas and reflection.
This was an interesting read, thanks for the recommendation! It reminds me of “zero inbox” for email.I wonder how common this approach is. Interesting idea to let bug reporters add the context of the risk of not fixing the bug and how much of a problem it poses to users to make it easier for the entomologist to make a decision.
