How to fill out a bug report

Useful bug reports are the ones which help to get bugs fixed. Although this seems simple enough to adhere to, bear in mind that a bug report needs a delicate balance of enough details versus too many unnecessary details.

Of course, every bug report is different, and this depends on what you’re testing out and most certainly on the bug report template. You might be using a fairly standard template or an extremely tailored template with headings which are specific to your business or area.

It goes without saying that in order to fill out a bug report correctly, you need to know what all the different things mean. Here are a few of the more general terms you will find in bug reports, so that you can learn what you need to fill in.

Where did you find the bug?

Product:

In which product did you find the bug? This might be obvious to you since you’re probably looking at the product right now, but don’t assume that whoever will fix the bug knows what product it is you’re using or testing.

Version:

In which product version did you find the bug? Just as important as the product. For a start, the developer will check to see if it’s a version specific bug or if it’s spread across multiple versions.

Secondly, if you’re running an older version and the bug was fixed in subsequent updates, there will be less motivation to fix that unless there is a pressing business concern.

Sub system/component/module:

In which sub system does the bug exist? Most software has a number of sub systems. If we take a social networking site which works impeccably until you try to watch a video on it, then you know which component is problematic.

Platform:

On which hardware platform did you find this bug? This makes a difference. Macintosh, SGI, Sun, PC. or even the computer manufacturer might all be viable answers, according to the circumstances.

If you know that the bug occurs on all hardware platforms, choose ‘All’. Otherwise, select the platform that you found the bug on, or “Other” if your platform isn’t listed.

OS:

On which Operating System (OS) did you find this bug?  Linux, Windows NT, Windows XP, Windows 7,  Mac OS 10.5, your choice makes a difference to how the bug is tackled

If you know the bug happens on all OSs, choose ‘All’, otherwise, select the OS that you found the bug on, or “Other” if your OS isn’t listed.

Browser:

Some bugs appear only in certain browsers such as Internet explorer or Chrome. Just like the software you are testing, the browser comes in several releases and all releases have separate version numbers. Choose your browser name and version number. You can typically find this information under the help/about menu.

How important is the bug?

Severity:

How damaging is the bug? The most appropriate severity for a particular bug depends on the scale you might be using (such as MoSCoW) or what your organization’s policy is. In any case, if unfamiliar with this area, it is best to ask someone who knows what your standards are.

Who will be following up on the bug?

Assigned To:

Which developer should be responsible for fixing this bug? Ensure that you know whom is tasked with what so that you don’t assign bugs erroneously. In some projects all bugs should be assigned to the test leader, who in turns distributes the bugs to the right developer.

What else can you tell the developer about the bug?

Title:

How would you describe the bug, in a clear sentence? In ReQtest you can use 300 characters for the title but it is recommended to be more concise.

A good title should quickly and uniquely identify the bug report. If not, developers will not understand exactly what the bug is by bug title , and will often not pay attention to your bug report, especially if they happen to be reviewing a 10 page bug list.

A title saying “Drag-scrolling on any web page crashes Mac builds” is a useful title. “Crash” or “Drag Crash” would be examples of a bad title.

Description:

Here you should provide as detailed of a problem diagnosis as possible, including as much as possible of the following information:

Test steps:

Describe what you did to evoke the problem. If you are executing a test case, add a link to the test case so the developer can read it for more details. Often it is wise to provide about 3-5 steps in a numbered list. It improves readability and therefore makes it more probable  that the bug is going to be fixed.

Expected results:

What the application should have done if the bug were not present. For example, if a directory window should be opened when you click ‘browse’ on the social networking site, and instead the browser crashes, specify so.

Actual results:

Here note what the application did after performing the above steps.

Additional Information:

Is there anything else you like to tell the developer about this bug? If you have debug logs, event log information etc you can add it as an attachment to the bug. If you wish to include a screenshot to clarify the bug report, feel free to attach an image. If you use ReQtest you can easily create screenshots via the built-in program ReQtest Capture.