1 minute read

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.

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.

A bug report must be user-friendly

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

What?

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?

Where?

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.

When?

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?

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.