Bugs are everywhere – and you’ll always have users report that something in the software you might be working on is “broken”.

First and foremost, it’s tough to create an advanced piece of software that will work exactly the same on every of your user’s computer.

Differences in computer hardware, operating systems, and software environments can cause bugs to appear on some machines but not on others: that’s because there are so many differences across various Operating System’s (OS) APIs, the hardware the machine is running, and just the OS configuration alone. There are even more quirks, for example, differences in compilers/interpreters used to build an executable.

To use a metaphor, it’s like repeatedly cooking a dish with slightly different ingredients – or different quantities – every time. You might notice the difference if you pay attention to the flavor profile, but not always. Similarly, the environment where the application runs always changes a little on every user’s machine.

When bugs occur in specific environments, developers need sufficient information to reproduce them before they can be fixed. Isolating the minimal conditions and steps required to trigger a bug is crucial.

And do developers get that information from their customers?
The answer is almost never.

Bug reporting by the user

Many software products allow users to submit bug reports or feedback directly to the their team: an automated bug reporting system, opening a ticket in a bug tracking system, sending an email to an email inbox, file a report through a customer support portal, or in more recent times, open a thread in a community forum or initiate a bug report through an A.I. chatbot.

More often than not, user bug reports lack enough detail for developers to efficiently diagnose and fix the issue.

In my life I’ve seen a fair share of bug reports.

From that experience here are the biggest reasons why users aren’t great at reporting bugs

No steps to reproduce

Users will often miss or give not enough steps to reproduce a bug. Without the exact steps to reliably recreate the bug, it’s very difficult for any developer to investigate it and resolve it a bug.

For example: I was doing this, then I did that, I expected this to happen but instead this else

Vague descriptions

Bugs should be reported clearly and coherently so that developers can understand the context and create a timeline of events to reproduce, tackle and solve any bug.

Unfortunately, that doesn’t happen often, especially when users who aren’t tech-savvy will often say something “the app doesn’t work”, giving very vague details, while everyone in the dev world knows that specifics are the key.

Missing context

Details and metadata around a bug are also important to recreate the environment where a bug occurred. Things like what operating system, browser, application version, or hardware the bug occurred on are essential.

Not reporting the full error messages

Any error messages, stack traces, or logging output displayed on the screen, could contain vital clues to trace the source of a bug. These should be included, but users often don’t have the tools to get those in time, when a bug occurs. Particularly, if the bug is visually observable, screenshots, videos should be attached to reports.

Lack of follow-up

This is probably the worst offender of a bad bug report. After submitting a bug, users who do not reply to developer follow-ups. aimed at reproducing or diagnosing the issue.

The best bug reports

The best bug reports are the ones you take while running Dashcam because they help you show a developer the full context of a bug as it happens. This way you can file an issue or bug report with all the relevant information captured on your machine at the exact time of the bug appearing. This will allow developers to reproduce the bug you reported with the most confidence.

It’s important to take time to craft a detailed, reproducible report, it truly makes a fix much more likely.