How to write a proper defect(bug) report

One essential task for a tester / QA / SDET / developers is to file defect reports. A defect report can be time consuming especially if it is not done correctly.

The purpose of a bug report is to document an incident that did not follow the expectations or requirements of the product / services. This is to ensure that there is some form of documentation so that the team members may follow up later when they have time to investigate

What is a bug ? The definition is :

A system that produce an incorrect or unexpected result, or to behave in unintended ways.

What should be inside a bug report

Summary
Description
Reproducible Steps
Expected Result
Actual Result
Severity
Feature affected
Build
Platform
Environment
Dependencies
Attachment

Summary

Summary is the title of the bug report . It can be like

Unable to login user in Stock System (Chrome)

Be concise in your report. If it only impacts certain browsers or platforms , put a bracket “(Chrome)” or some labels in the summary so that anyone can filter the results

Description

This explains the summary in greater detail. You can describe what happen, general observation and what you did to investigate. Example

When login as user id “tester123” with password “123456” in Stock System login page, there is no response or error. I open up Chrome browser dev tool and inspect the elements xxx and …”

Reproducible Steps

Reproducible Steps (Repro steps in short) is one of the most important steps here. Put your shoes in the perspective of your team mate (example developer) when they are looking at the report. Will they understand the steps without asking you to come over to demonstrate the bug? Example of a repro steps

1. Launch url stockexchange-test.env.com
2. Input “tester123” in login field
3. Input “123456” in password field
4. Submit button

Expected and Actual Results

Expected results are designed results which the team / requirements agree upon. Actual results are observed recorded results when we execute the test. Example

Expected Results

User login successfully and should be in user profile page

Actual Result

User profile page did not show. There is no error message

Severity

How severe is this defect ? It may be Showstopper , critical , major , minor , tweak , usability in some cases. In some defect tracking system , the quality assurance policies may dictate to include other mandatory fields like crash , system failures , error message etc. In other system, this may also include priorities. Severity indicate from the reporter point of view how “bad” is the unexpected. This can also be decided by the team members later on in a defect meeting.

Feature Affected

Feature affected are important for metrics filtering. In the login in error, the feature may be “Authentication”. This allow quick filtering especially when the team is looking for similar cluster issues to fix in a sprint.

Build (or commit-id )

Build is crucial . It involves the developer to reproduce defects using the same build. Without it, it is impossible to to trace when the defect was found.

Platform

Platform can be mandatory. Example in mobile — iOS / Android . Or browser — Chrome , Firefox , Safari , Opera . Or OS X Majove 10.14.6, Windows 10 , Fedora 31

Environment

Environment is where the test is executed. It can be testing server / developer server / staging server or production .

Dependencies

This is additional libraries or plugins which one need to install on the main system to reproduce the defect. It is important that we include this as every device may not be in a clean state.

Attachments

Attachments are supporting document to ease the understanding of Repro Steps. Attachments can be screenshots (image or video) or extract of requirements or others which help to support your case. Think of it that you are the prosecutor and you need as much evidence to convince the judge (developer) that this is the bug. Make life easier for the developer by attaching video or screenshots so that he/she can repro it on spot.

You can see that writing defect reports involve significant amount of time. However, if we create a report that our team members do not understand , it will result in more wastage of time to reproduce the defect in someone’s workstations.

Do it right now , or do more later.