Perhaps you’ve read somewhere that the only valid measurement of code quality is “WTFs per minute”. I’ve noticed that WTFs tend to begin way before a line of code is even written… at the source (not code, ha!), but at the ticket level.
Vague and unclear tickets tend to do more damage than good if a fix is committed and deployed, and the ticket is sent back or re-opened as the functional requirements were not met. The back and forth becomes tedious and wasteful of everyone’s time.
Team deadlines get postponed as resources are tied up to that ticket, and tickets written horribly are not picked up by your team members because they are intentionally avoided. Think about that for a moment.
Bug Reporting - Uberflip Style
The dev team at Uberflip is close-knit. We welcome questions and keep open communication with one another. We also foster innovation to improve day-to-day tasks and streamline processes to benefit the team. I want to help my teammates as best as I can. One way I have found to achieve this is by reporting bugs as clearly and concisely as possible.
Effective Strategies for Creating Bug Tickets
Clarity is key - Don’t be vague. Write the ticket title after the description, to ensure that the “main idea” has been captured.
Use ordered lists when lists or steps are required - Lists make the ticket easier to follow, as well as refer to if the ticket gets sent back for feedback.
Avoid crying Wolf! (as much as possible) - Once a bug or discrepancy is found, try to recreate the bug until steps for recreation can be established or a self-defined number of attempts have been reached. This will not only increase the ticket turnover rate, but also reduce the number of times a ticket has to be sent back for feedback. My main goal in reporting a bug is to aid a team member in identifying the root cause(s) of a problem. If you’re reporting bugs, and they’re not actually bugs, you lose trust and credibility amongst your team.
Provide as much information as possible in the ticket description - I’ve found the S.T.A.R. approach to storytelling to be helpful in structuring a clear yet concise description when a bug is not as clear cut as “Go to page x which you will see looks completely wrong.”
Here’s how we break down the S.T.A.R. approach
Situation
- The environment where the bug is identified, e.g. development vs. staging vs. production
- Backend or frontend
- Page/location where the bug was found
- Device (if applicable, indicating browser and/or OS) - Details such as device and browser can be vital in identifying where the problem is, and also help determine how vast the problem may be. This is common with bugs related to layouts or display.
Task
What was I attempting to achieve? e.g. I was attempting to create a new custom stream
Action
What steps did I take to perform the task? e.g. Creating a new custom stream through the Smart Filters modal
Results
- What was the expected result? What was the actual result? Were there any browser console errors or server-side errors? Depending on the context of the ticket, any logged error messages, along with their corresponding access log entries may be included.
- A picture is worth a thousand words: Provide screenshots where descriptions may be difficult, and annotate the screenshots to provide clarity.
Our Bug Reporting Template At Uberflip, we created a button that populates the following bug report template in our ticketing system, to encourage more comprehensive tickets that looks like this:
*---------- REPORT ----------*
STEPS TO REPRODUCE:
EXPECTED RESULT:
ACTUAL RESULT:
PLATFORM/BROWSER/OS/BOT APPLICABILITY:
My hope for you as you incorporate these strategies in your bug reporting, is that your peers will follow suit and WTFs will be restricted to the code review process only.
How does your team go about doing effective bug reporting?
About the Author
Follow on Twitter More Content by Keri Wong Chew Onn
