Realizing your product has a bug can be annoying or even terrifying – they can be baffling, mysterious, and extremely harmful to your brand. Describing what happened in a way that gives developers everything they need to know to fix it can be an intimidating task if you don’t have a good gameplan.
Imagine someone has run into an issue with your app or site, and now you need to record what happened so your team can fix it.
You could send something to your devs that looks like this:
“Checkout broken” [and a generic screenshot of the checkout screen]
Your devs hate bug reports like this. This tells them nothing about what broke, what caused it to break, or how they can replicate the issue. You need to give your devs enough context that they can replicate the bug to figure out what (if anything) went wrong. But you don’t want to swamp your devs with irrelevant information.
How do you make sure you give devs exactly what they need to diagnose and fix a problem?
A great bug report template
When reporting a bug, you need to communicate to your team what led to a bug so they can replicate it, figure out what causes it, and fix it. More often than not, you’re not privy to what caused the issue or exactly what information is valuable for getting to the bottom of the issue. You’re just the messenger. You’ll need to report everything a developer might need to know without making reading the bug report more work for your developers than fixing the bug.
Thankfully, writing a good bug report is more science than it is art– after hundreds of hours of research, here's how PlayerZero structures reports:
This makes referring to the bug and keeping track of its status much easier. Make sure you are consistent with whatever bug identification system your team uses
A good title briefly summarizes what the bug is so someone who sees the bug report immediately gets a rough idea of what happened and who should be assigned the issue.
Who is reporting the bug, so that devs know who to ask for more information or clarification.
Date/time issue occurred:
This helps devs understand whether a change they made is responsible for the issue and also helps you keep track of how effectively your team is resolving issues.
Platform/browser used(ie. metadata):
This is crucial information for replicating an issue if compatibility with an operating system or browser is partly to blame for the issue,
Steps to reproduce:
Here is where you need to recount what was supposed to happen, what actually happened, and all the relevant actions leading up to the issue. We've simplified this process so you don't have to answer the questions we've heard over and over:
- How detailed should you be? You want to be thorough but concise; don’t give your devs more work by writing a novel.
- Which details might matter? Make sure the details you include are the right ones. Whether a user had logged in then logged back out might matter, but the fact that they chose purple shoes instead of blue ones likely doesn’t.
- What went wrong? What is the problem? What does it prevent you from doing, and what does and doesn’t work to avoid it?
Screenshots are invaluable for helping devs understand where a problem occurred and what might have caused it. Recordings are even better; if you can record yourself reproducing the issue, the dev has a great chance of either reproducing it themselves or at least learning that some behind the scenes factor not captured on the recording is crucial to the bug.
Priority and severity:
How urgent is this bug, and how significantly does it affect your application? This helps your team prioritize issues.
Full devtools, giving devs what they need to see upder the hood!
Conversation and activity log:
For those participating in the debugging process to refer back to at any point.
Bug reporting is an entire skill unto itself – you have to remember what happened (or be very good at asking questions to help a user remember what happened), understand what information is and isn’t relevant to developers, and convey that information clearly and concisely in a tone your devs will be receptive to.
We at PlayerZero think manual bug reporting should be a thing of the past, so we’ve built a tool that does the job of reporting bugs with full context for you.
PlayerZero, the best bug reporting tool
A good bug reporting tool would provide devs with a full account of what causes a bug and how to replicate it. An ideal bug reporting tool replicates a bug by itself. PlayerZero does just that.
Here’s how it works:
With the click of a button, PlayerZero captures the full context of a user session – when it happened, where it happened, what happened, and who did it. This allows anyone to simulate the user session in whatever environment they prefer, so your devs can simulate the session locally and test out bug fixes before implementing them in production. You don’t have to recall what clicks were made or which order pages were visited, because PlayerZero shows your devs exactly what happened.
Why this is built perfectly for engineering teams
- Send a link to this session on whatever platform you use to communicate issues.
- Highlight important steps and comment on what you think is most worthy of attention.
- Open up this link and simulate the session on their own machine, in whatever test or product environment they choose.
PlayerZero takes over the tedious part of bug reporting, so you can focus on finding more issues and delighting your users and your devs can fix issues faster. Bug report writing is a skill that you don’t need to master, because PlayerZero already has, see for yourself: