Better Bug Reporting: Spare Your Colleagues the Request for a Ticket
In a quality-driven engineering culture, staying on top of product defects is vital. After all, bugs exist — whether you know about them or not. The question is: Who will be the one to discover them first: You or your users?
When reaching out to the owners of a feature to report a problem, I am sure many of you will have heard the following response throughout your professional career:
“Could you please create a ticket for that bug?”
Seen from the surface, there is seemingly nothing fundamentally wrong with that reply. I admit, I have (unfortunately) used it myself at times in the past. And I am sure you have as well.
The communication issues with that request happen to lie on the deeper levels beneath. Broken down into its rawest essence, instead of rewarding an action, you might end up accidentally penalising it.
Remember, we want to build a culture where everyone is enabled to report as many problems as possible with zero friction.
Let’s take a look at three different levels at which such a response might prompt emotional and psychological reactions. Understanding and addressing those will help you to collaborate better as a team, especially when working with user-facing products.
💡A quick side note: This article talks about internal communication when it comes to defects. If you run a product with a public issue tracker the points outlined below only apply partially as consumers will naturally be the ones filing tickets.
Level 1: They have reported a bug already, is there a good reason to make them do it again?
The first point worth questioning is: Who will end up creating the ticket? If the reporting person goes to your issue tracker on their own devices and files that bug themselves — good for you!
However, if they have taken the time to describe a problem (maybe even along with a screenshot and the potential root cause) in your Slack channel, what stops you from taking care of that yourself?
Don’t get me wrong, some people might do it gladly. But by requiring the bug finder to create the ticket after they already got in touch with you, it could, subconsciously, trigger the following questions:
👉 “The team seems too busy to record the bug I have raised, are user satisfaction and quality really top of their minds?”
👉 “I have already invested my time to find the right people to contact and describe the problem, why do I have to do it again?”
👉 “If I don’t file the ticket myself, will anyone take care of that or will the bug go unattended?”
Key takeaways: As you might notice, the way your team handles the initial contact, tells the reporter (albeit subtly) about your internal culture. This might put you in the wrong light and give a misleading impression.
Level 2: You own the feature, not them. You know the system behind it and the correct language.
Imagine you are reporting a bug. After struggling with the write-up for the description (let alone finding a snappy title) you feel like you’ve managed to get your point across and file the ticket.
Soon thereafter you get an email. Some of your words have been replaced with different terminology. Maybe a paragraph has been edited completely. Plus, some comments are asking for further clarification.
You are a little bit surprised as you had just been chatting with that team on their channel. What’s the reason these questions hadn’t come up earlier? If you would’ve known what to focus on a little bit sooner. you could’ve saved a lot of your time.
Reporting bugs takes up time on both sides. The more inefficient the process feels the less inclined team members are to raise and look out for bugs.
Again, here are some examples of what people around you might feel:
👉 “I am not an expert on that feature. Am I using the right language to describe the issue?”
👉 “Getting the description right is taking a lot of my time. I don’t feel that I should be the one doing this.”
👉 “I got a lot of edits on the ticket I just created. Why didn’t the team seek clarification when we were talking about the bug earlier?”
Key takeaways: Having to write a ticket produces a lot of cognitive load which might go as far as the person reporting a bug might feel punished for having found it in the first place.
Level 3: Don’t be ungrateful. Reward new bugs and acknowledge duplicates generously.
When someone reports a bug to your team, chances are that you will be able to pigeonhole the issue into several categories: Severity, frequency, uniqueness, etc.
That someone, however, is very unlikely to have that knowledge. To them, it’s a bug just like any other. What counts first and foremost is that they were the ones who found it.
Upon being contacted about a potential software defect, some teams immediately jump into micro-crisis mode; either “deflecting” the problem by marking it as already known or deferring having to pay attention by asking to create a ticket.
By turning the focus towards themselves, a team might end up prompting these thoughts in the reporter:
👉 “I spent the time describing a problem. It would’ve been nice if it had been met with the right level of appreciation.”
👉 “My interest was not to find out whether or not the issue was a duplicate. All I wanted is for this to be handled with care.”
Key takeaways: Watch out for micro-crisis mode in your team. Don’t shift unnecessary work to the person reporting a bug. Instead, show the right level of appreciation.
Solution: How to create a bug culture like a pro in your team
The way your team approaches bug reports will fundamentally change their external image for the better. Plus, the good news is that making that shift is extraordinarily easy.
Here is what you need to do to become a true champion at dealing with incoming bug reports:
- 🎯 Always be welcoming and grateful. No matter what the actual issue turns out to be — someone has taken time out of their schedule to report a problem. Always make sure to thank and encourage them to come back with anything else they might find.
- 🎯 Unless it’s already there, you are the one to create the ticket. You know the most about the features you create. If a reporter already gave you information about the bug they found, go ahead and copy those into a ticket on their behalf. It also gives you the liberty of adjusting the content without wasting the finder’s time. Once you’re done, invite them to add any details to the ticket that might be missing.
- 🎯 Be transparent about your actions. You might end up closing a ticket as a duplicate or moving it to someone else’s project. Always make sure to post a comment that explains your actions. It’s very discouraging to have your ticket closed for no apparent reason.
- 🎯 Make the reporting process an absolute breeze. Reported or not, bugs exist. Raising them should be a frictionless process. Your goal should be to make it as easy as possible for everyone around you to step forward and post an issue. Assist where necessary, and ensure the heavy lifting is on you.
- 🎯 Respond timely to capture as much detail as possible. A quick initial response (not to be confused with the classic help centre auto-reply) not only shows your attention to quality but also helps to seize the potential of the moment. Engaging in the conversation will increase your chance of getting useful in-situ details from the reporter. The odds usually get drastically worse the longer the comment ping-pong of a ticket drags on.
With these quick recipes implemented, you will appear much more accessible and come across as a team that truly owns the software they build. On top of that, the ease of the process and the appreciation you show towards the people who get in touch with you will encourage them to raise issues as they face them.
Never forget: You’re lucky for every bug that sneaked past your tests but got found before harming actual customers. So it’s just the right thing to repay the favour and make reporting problems an absolute charm!
Hi, I’m Friedrich! I’m a manager and developer at work, a hobby chef, musician, data & language enthusiast at home. You can find me on LinkedIn.
If you want to support my — and other authors’ — writing, consider becoming a Medium member.
