I recently talked with someone comparing bug tracking to solving criminal cases. And I think there’s a lot of truth in it. Like police inspectors, we as developers rely on evidences which we gather through asking the right questions. A well-executed bug reporting strategy will bring answer to these questions.
In this post I’m going to show you four essential questions I wish every bug report answers.
From a developer’s perspective a bug report must contain every single piece of information that helps to track down a software problem. From a QA agent it’s often hard to write bug reports in an efficient manner containing the right quantity & quality of information.
There’s a difference between a bug report and a bug report
Well, if you think of bug reporting and bug reports, you’d probably envision some lengthy forms about the issue types, priorities, components, affected code versions, resolution, status, etc.
I know, I’ve been there too and I know from both sides how annoying it can be. As a developer who don’t want to ask for additional information on every single, little bug. As a QA agent you don’t know about every technical subject in detail and you don’t have the time (in many cases) to provide lengthy descriptions.
A bug report must be user-friendly as well
As mentioned a bug report must store all information needed to track down problems and fix them (and in best case scenario: in an efficient manner). In order to achieve that a bug report must be one thing: user-friendly. It’s irrelevant what information is requested, unless it’s done in a user-friendly way. This means that we have to re-think the way how we create bug reporting forms and questionnaires.
The Four Ws of information-gathering
If you type “bug report” in Google’s image search, you’ll see why a lot of people (especially non-tech people) have some discomfort regarding the field of bug reporting.
That’s probably the most important question every bug report should answer. That’s what bug reporting is about. “What happened?”
The question about “what happened” should address what the user or tester did before a problem occurred. Has there been any action taken place by the website visitor – e.g. a click on a certain button or just some mouse-over?
Without the place of the “crime scene” a description of the crime itself won’t help any inspector in the world. Answering the question of “Where did it take place?” is essential. Whether it’s by providing the URLs or environment information about operating system, browsers or hardware. This information should be included on every single bug report.
The time frame when something happens is truly important for developers in order to track down issues. So answering the question “When a problem happened” is key. However, it’s pretty hard for QA agents and testers to describe. Of course you can state the time when it happened, however it’s not easy to re-call the exact moment or time when some problem happened for the first time.
As you see: answering the question of time and when something happened, provides some in-depth knowledge.
Who was the person who discovered the issue. What’s his/her name, what his/her location, what’s his/her email address. There are not many things which are truly important for tracking down a bug. Name, location and email address probably are fine in the beginning.
Of course there many additional questions which can be asked. However, it’s key to keep it to precise and easy-to-answer questions.
And what if all these questions are answered automatically, simply by pressing one button? Well, we – at Usersnap – try to do that. We aim for a bug tracker which not only provides developers the right amount & quality of information, but also to make bug tracking as easy-as-possible for everyone involved. And looking at the feedback we get from our truly inspiring customers, I guess we’re on the right track for that.
Image filing a bug report like this:
You don’t think that these kind of bug reports will help solving issues? Well, at least these bug reports automatically add every information on:
- What happened (through annotations on the screen),
- Where it happened (through automatically adding the URLs of page where the problem occurred),
- When it happened (through adding time stamps),
- And who filed the problem.
What’s the most important part of every bug report from your point of view? Let us know in the comments or on twitter.
This article was brought to you by Usersnap – a visual bug tracking and screenshot tool for every web project.
6 surprisingly easy bug tracking hacks every developer should know
When it comes to bug tracking there’s a lot of discipline required from everybody involved. Tracking & solving bugs encourages everyone involved to stand to the rules. Especially in creative- & startup-driven industries it can be pretty hard to discourage any informal communication. And in many cases people won’t name bug tracking as their favourite part of…
14 extremely useful Chrome extensions for developers
A couple of months ago, we reviewed the new Firefox browser designed for developers. Since then most of our developers kept Google Chrome as their primary browser. Working with Chrome offers access to an immense repository of Chrome extensions and tools which make our daily tasks less of a chore. With the built-in developer tools,…
Autumn Update: New pre-selection setting & Bitbucket integration
The Usersnap team was working hard on some neat features for our 3rd party integrations in the last weeks. Besides our new Bitbucket integration we’re excited to offer you a pre-selection possibility for your connected tool. Learn more how it works!
11 best web development blogs you should be reading right now
This article is brought to you by Usersnap – a visual feedback & bug tracking tool, used by software companies like Facebook, Google, and Microsoft. Creating software isn’t that easy. There is a ton of things to consider. The more you actually create, the more you’ll learn. And since there are many developers out there who share…