Reduce confusion, miscommunication and that annoying back and forth managing bugs, using this template.
What is “done” when you’re referring to bug tracking? What’s “done” for one person in the QA process could be “in-progress” for another. Without a process in place or bug reporting template, bug tracking can be a downright chore.
It doesn’t take long for inconsistencies in reporting to lead to follow-up emails, bugs getting left behind, and the QA process resembling more of a “free for all” than a defined system.
The benefits of having a clear and repeatable bug tracking template can be beneficial in many ways:
- Provides an at a glance, comprehensive and accurate report that the entire team can access and refer to.
- Removes ambiguity around who is working on what, and what stage a bug is in.
- Reduces time spent on seeking clarification on bugs.
- Increases productivity by providing a framework for teamwork.
Here’s what we believe are the elements of a bug report that will keep your team on track and developers happy.
THE ELEMENTS OF A GREAT BUG REPORT
1 – Bug ID or Name
To ensure each bug is clearly identifiable, trackable and manageable it is extremely important to make sure each is given a unique ID or name.
This will be a massive help to you and your team both in the present and in the future, especially in times when you’re trying to find that one bug you need to find … but just can’t find it right when you need it!
With a proper naming or ID’ing system in place, you’ll always find what you need. It can be as simple as something like this:
In the above example, simply labelling the bug as #150 means that you and your team will always have an easy way to search for it whenever you need it.
2 – Title or Short Description
Once you have given the bug a name or ID, it’s important to write a short title and/or description that outlines exactly what the bug is.
This ensures that everyone on the team is on the same page about the issue and no one is left guessing. Here is a snapshot of a short description you could write for the above example:
Presto! You and your team and now all on the same page and everything you wanted to be known is now clear.
3 – Severity
Will it be the end of the world if this isn’t fixed in the next hour, or can it wait a week?
It is always important to let your team know how important a certain task is to fix. This way they can prioritise what needs to be done first, so you’re not left launching a landing page for example without what’s important … not fun.
Even better, you can set up a system of importance from ‘not so important’ to ‘this better be done before my coffee machine is done!’ This way, your priorities follow a widely understood system of importance.
Here’s an example:
Easy as that. Simply select the option that reflects the bug’s level of importance.
4 – Environment & URL
What browser and operating system was the bug glitching in? What exact URL was causing the problem?
These are all extremely important questions to have answered for the people working to fix them. If you do not specify the environment that the bug was occurring in, well then no one knows where to look for the problem!
Here’s a simple template you can use to do just this:
Not much more to it. The more specific you can be with where the bug was found, the easier it’ll be for others to suss it out for you.
5 – Screenshot
Arguably the most important part of the bug report – a picture truly tells 1000 words.
An annotated screenshot, showing where the exact location of the issue is can reduce time searching on the page. It provides a visual reference for not only where exactly the problem occurred but also what has happened.
Your screenshot could look something like this:
By including a ‘pin’ in the screenshot or some other kind of indicator of where the bug occurred, you provide better context to your team to find it.
6 – Steps to reproduce the issue
Can you provide more clarity on what was going on when the issue appeared?
When it comes to bugs and reporting them, it can be very important to your team to let them know as much as you can about the environment it was created in.
This is because some bugs simply do not show up unless a particular set of criteria are replicated. The more details you give the more time you save solving the issue. A simple comment like this one usually suffices:
The comment above makes it extremely clear for the team that the issue is only on mobile. A ton of time has been saved by not trying to resolve the issue on desktop.
7 – Metadata
You may not have access to this, but providing the selector data, screen resolution and browser size would win the hearts of many developers.
This is the final step in the process but can sometimes be the biggest difference between a decent bug report, and a great one. As with this example below, the more you can include the better:
There are plenty of ways to track and record all of the above information information. It is common to have it all in one ungainly spreadsheet.
We, of course, recommend you use a Bug Tracking System to track, speed up and manage your QA process. BugHerd provides you with a powerful & simple visual feedback tool to do just that, including all of the above elements.
Plus a customisable task board makes it effortless to manage tasks and track bug reports, from start to finish. Huzzah!
Thanks for reading! If you love this resource, we’d love your shout out over on our Twitter! Looking forward to chatting with you there.