Simple Hacks for Bug Reporting and Tracking: 5 Tips to Empower the Whole Team
Within a company, everyone works for the same team, but when everyone has a different skill set, area of expertise, and access to varied information, it can begin to feel like not everyone is playing the same game. With information fragmented across multiple platforms, it becomes difficult to find guidelines for company procedures. Once, and often if, you can find instructions for a given task, it can be difficult to follow them according to protocol, let alone keep the rest of your team in the loop about what you’re doing. Bug reporting is no different. Far too many companies lack a streamlined process for dealing with technical issues in a simple, documented, and accessible manner.
Though a bit overused, the old saying rings true: your team is truly only as strong as its ‘weakest’ link. When it comes to bug reporting, this weak link takes the form of anyone who does not feel empowered to effectively report a bug, and they may also become your company’s Achilles heel. Non-engineers use your product; they market it, sell it, and so on, so they should play a key role in reporting when something goes wrong. Too often, companies don’t take the time to cue in their less technical employees, thus undervaluing a key resource for bettering the product and making fixes more efficient.
Culture is Everything
When company culture doesn’t empower everyone on the team to take action, important tasks fall through the cracks or are carried out incorrectly. Bugs may be reported ineffectively, multiple times, or worse- not at all. Thus, it is essential for every SaaS company to create and distribute streamlined guidelines for bug reporting and tracking. This will empower your entire team, make life easier for your developers, and ensure that your employees are not only on the same team but are playing the same game.
What You’ll Need
Bug tracking software can be helpful, but it can also be expensive, and for smaller teams, unnecessary. In fact, manual internal bug reporting can actually help your team stay aligned with goals, as it involves cross departmental communication and collaboration. Non engineers have an opportunity to better understand the software behind the UI, and engineers gain insight into the trials and pitfalls of the user experience. All you really need is...
- Tool for task organization
- Tool for smooth communication
At Xoba, we use Asana for task tracking and Slack for communication; it’s an extra bonus that the two can be integrated together. However, if your company is less familiar with these two applications, a simple Google sheet and email chain will suffice. (For a spreadsheet, I would recommend including columns such as title, description, date found, assigned developer, and date of resolution to stay organized.)
Steps to Success
Once you’ve decided on the best way to organize and share information across your company, you’ll want a consistent process. Here are five foolproof steps to garuantee that everyone in your teem feels confident reporting bugs and that they get resolved with speed and efficiency every single time.
- Check for duplicates.
As mentioned, Xoba reports and tracks bugs in Asana. This allows us to add them to our ‘To-Do List’ immediately and check them off as soon as they’ve been taken care of. To avoid reporting a duplicate bug, check to see if a task regarding a similar issue has already been created. Sometimes this requires technical knowledge, so team trust and cooperation play a key role. Non-engineers: do your best to thoroughly go through existing reports. If it seems like a unique issue, write up a task for it; if it seems like a possible duplicate, note that in the description. Engineers: trust that the rest of your team put effort into the report and that any double-documentation was accidental. Everyone should remember that it’s better for a bug to be reported multiple times than not at all.
- Document the issue.
Once you’ve double checked that there’s no pre-existing task that addresses your problem, create a new Asana task with a concise title describing how the bug manifested (e.g. "Duplicate rows in the Applications page"). Then, write a description with more detail. Every bug report should include how you got the bug to appear so that it may be reproduced. It may also be helpful to note your estimation of how severe the bug is from a UX impact perspective to help indicate how high priority the fix is. If possible, add a screen recording or screenshot of the issue.
TIP: Bubbles is a free tool that allows you to make notes directly on your screenshots and screen recordings before sharing them with your team. When reporting a bug, Bubbles allows you to point out exactly where the issue is on your screen and note steps to reproduce it all in one place.
- Notify your developers.
At Xoba, we use Slack enough to know that someone is always online to intercept a bug report. You can even integrate Asana and Slack to send to notify specific channels or group members when Asana tasks are created and resolved. Whether you prefer this automated method or a personal, hands on message, notifying your engineers immediately is key. If a bug is affecting one of your employees, it's likely also affecting many of your customers and should be identified and dealt with as fast as possible.
TIP: Any further discussion about the bug should occur within Asana. Slack is great for notifying your team but not an ideal long term archive (especially the basic version with limited storage). Commenting back and forth on the Asana task is efficient, and it also allows developers to revisit how they solved the issue when similar problems arise. (If you’re using another platform to discuss, like IM or email, summarize and archive the discussion afterward in a Google doc or internal file).
- Empower your engineering team: Review> Assign > Solve > Resolve
This four pronged approach is actually quite straightforward. Your engineering team should read over the task, ensure that it’s not a duplicate, and evaluate the severity of the issue. Then, assign responsibility. For some companies, bugs may be divided up by front versus back end. Other companies may delegate the issue to whoever is ‘on call’ whenever it’s reported. Regardless of how you determine responsibility, the decision should be swift and the method consistent. Finally, the assigned developer will solve the bug and resolve the Asana task (or mark off the Google sheets column, etc) so that everyone on the team understands the state of the issue and when it has been or will be fixed.
- Document this process and make it accessible to your entire team.
This step may seem like the simplest but it is also probably the most important. Blog posts like these are no good when only one person on your team reads them. As described above, your whole team needs to feel empowered to execute these steps, and to do that, they need to have them at their fingertips- always. We use Notion for internal documents, so our bug reporting best practices reside there, but your company might prefer a pinned Slack message or Google doc. Wherever the guidelines live, they should be kept up to date by engineering, reviewed frequently, and accessible to everyone who may need them.
Bonus Step: Give Xoba a Try
Throughout this process, we use Asana, Slack, and Notion. You might use a combination of these, or other platforms like Gsuite or personal email. Xoba acts as a knowledge engine, powering your bug reporting process. It connects all of your applications and streamlines information discovery across all of them. With Xoba, you can search for a bug’s title and instantly discover all related information, including documents, messages, tasks, and more. With information and discussion fragmented across so many platforms, Xoba enables your team to remain united.
