{"id":2794,"date":"2015-04-08T12:09:52","date_gmt":"2015-04-08T10:09:52","guid":{"rendered":"https:\/\/usersnap.com\/?p=2794"},"modified":"2025-02-25T08:19:02","modified_gmt":"2025-02-25T07:19:02","slug":"bug-reporting-solve-criminal-cases","status":"publish","type":"post","link":"https:\/\/usersnap.com\/blog\/bug-reporting-solve-criminal-cases\/","title":{"rendered":"The 4 Ws of bug reporting – Or how to solve bugs like criminal cases!"},"content":{"rendered":"\n

I recently talked with someone comparing bug tracking to solving criminal cases. And I think there\u2019s 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<\/strong> will bring answer to these questions.<\/p>\n\n\n\n

In this post I\u2019m going to show you four essential questions<\/strong> I wish every bug report answers.
\n<\/p>\n\n\n\n\n\n\n\n

From a developer\u2019s perspective a bug report must contain every single piece of information that helps to track down a software problem. From a QA agent it\u2019s often hard to write bug reports in an efficient manner containing the right quantity & quality of information.<\/p>\n\n\n

Try Usersnap for Bug Reporting<\/h2>Try Usersnap Now<\/a><\/div>\n\n\n\n

There\u2019s a difference between a bug report and a bug report<\/h2>\n\n\n\n

Well, if you think of bug reporting<\/a> and bug reports, you\u2019d probably envision some lengthy forms about the issue types, priorities, components, affected code versions, resolution, status, etc.<\/p>\n\n\n

\n
\"bug<\/figure>\n<\/div>\n\n\n

I know, I\u2019ve been there too and I know from both sides how annoying it can be. As a developer who don\u2019t want to ask for additional information on every single, little bug. As a QA agent you don\u2019t know about every technical subject in detail and you don\u2019t have the time (in many cases) to provide lengthy descriptions.<\/p>\n\n\n\n

A bug report must be user-friendly as well<\/h2>\n\n\n\n

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.<\/strong> It\u2019s irrelevant what information is requested, unless it\u2019s done in a user-friendly way. This means that we have to re-think the way how we create bug reporting forms and questionnaires.<\/p>\n\n\n\n

The Four Ws of information-gathering<\/h2>\n\n\n\n

If you type \u201cbug report<\/em>\u201d in Google\u2019s image search, you\u2019ll see why a lot of people (especially non-tech people) have some discomfort regarding the field of bug reporting.<\/p>\n\n\n

\n
\"bug<\/a><\/figure>\n<\/div>\n\n\n

What?<\/h2>\n\n\n\n

That\u2019s probably the most important question<\/strong> every bug report should answer. That’s what bug reporting is about. \u201cWhat happened?\u201d<\/p>\n\n\n\n

The question about \u201cwhat happened\u201d should address\u00a0what 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?<\/p>\n\n\n

Try Usersnap for Bug Reporting<\/h2>Try Usersnap Now<\/a><\/div>\n\n\n\n

Where?<\/h2>\n\n\n\n

Without the place of the \u201ccrime scene\u201d a description of the crime itself won\u2019t help any inspector in the world. Answering the question of \u201cWhere did it take place?<\/em>\u201d is essential. Whether it\u2019s by providing the URLs or environment information about operating system, browsers or hardware. This information should be included on every single bug report.<\/p>\n\n\n\n

When?<\/h2>\n\n\n\n

The time frame when something happens is truly important for developers in order to track down issues. So answering the question \u201cWhen a problem happened\u201d is key. However, it\u2019s pretty hard for QA agents and testers to describe. Of course you can state the time when it happened, however it\u2019s not easy to re-call the exact moment or time when some problem happened for the first time.<\/p>\n\n\n\n

As you see: answering the question of time and when something happened, provides some in-depth knowledge.<\/p>\n\n\n\n

Who?<\/h2>\n\n\n\n

Who was the person who discovered the issue. What\u2019s his\/her name, what his\/her location, what\u2019s 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.<\/p>\n\n\n\n

Conclusion<\/h2>\n\n\n\n

Of course there many additional questions which can be asked. However, it’s key to keep it to precise and easy-to-answer questions.<\/p>\n\n\n\n

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<\/a> which not only provides developers the right amount & quality of information<\/a>, 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\u2019re on the right track for that.<\/p>\n\n\n\n

Image filing a bug report like this:<\/p>\n\n\n

\n
\"modern<\/figure>\n<\/div>\n\n\n

You don\u2019t think that these kind of bug reports will help solving issues? Well, at least these bug reports automatically add every information<\/strong> on:<\/p>\n\n\n\n