Bug Report Template With Detailed Explanation

Defect report template or Bug report template is one of the test artifacts. It comes into picture when the test execution phase is started.

Earlier I have posted a detailed post on “Software Testing Life Cycle (STLC)”, if you haven’t gone through it, you can browse “Software Testing Life Cycle (STLC)” here

The purpose of using Defect report template or Bug report template is to convey the detailed information (like environment details, steps to reproduce etc.,) about the bug to the developers. It allows developers to replicate the bug easily.

See the difference between Error, Bug, Defect and Failure here

Check below video to see “How To Write Good Bug Report With Clear Explanation of each field”

Please be patient. The video will load in some time.

If you liked this video, then please subscribe to our YouTube Channel for more video tutorials.

Bug Report Template – Detailed Explanation

Components of Bug Report Template

Let’s discuss the main fields of a defect report and in the next post, we learn how to write a good bug report.

Defect ID: Add a Defect ID using a naming convention followed by your team. The Defect ID will be generated automatically in case of defect management tool.

Title/Summary: Title should be short and simple. It should contain specific terms related to the actual issue. Be specific while writing the title.

Assume, you have found a bug in the registration page while uploading a profile picture that too a particular file format (i.e., JPEG file). System is crashing while uploading a JPEG file.

Note: I use this example, throughout this post.

Good: “Uploading a JPEG file (Profile Picture) in the Registration Page crashes the system”.

Bad: “System crashes”.

Reporter Name: Name of the one who found the defect (Usually tester’s name but sometimes it might be Developer, Business Analyst, Subject Matter Expert (SME), Customer)

Defect Reported Date: Mention the date on which you have found the bug.

Who Detected: Specify the designation of the one who found the defect. E.g. QA, Developer, Business Analyst, SME, Customer

How Detected: In this field, you must specify on how you have detected such as while doing Testing or while doing Review or while giving Walkthrough etc.,

Project Name: Sometimes, we may work on multiple projects simultaneously. So, choose the project name correctly. Specify the name of the project (If it’s a product, specify the product name)

Release/Build Version: On which release this issue occurs. Mention the build version details clearly.

Defect/Enhancement: If the system is not behaving as intended then you need to specify it as a Defect. If its just a request for a new feature then you must specify it as Enhancement.

Environment: You must mention the details of Operation Systems, Browser Details and any other related to the test environment in which you have encountered the bug.

Example: Windows 8/Chrome 48.0.2564.103

Priority: Priority defines how soon the bug should be fixed. Usually, the priority of the bug is set by the Managers. Based on the priority, developers could understand how soon it must be fixed and set the order in which a bug should be resolved.

Categories of Priority:

High
Medium
Low

Read more on Priority & Severity of Bug.

Severity: Severity talks about the impact of the bug on the customer’s business. Usually, the severity of the bug is set by the Managers. Sometimes, testers choose the severity of the bug but in most cases, it will be selected by Managers/Leads.

Categories of Severity:

Blocker
Critical
Major
Minor
Trivial

Status: Specify the status of the bug. If you just found a bug and about to post it then the status will be “New”. In the course of bug fixing, the status of the bug will change.

(E.g. New/ Assigned/ Open/ Fixed/ Test/ Verified/ Closed/ Reopen/ Duplicate/ Deferred/ Rejected/ cannot be fixed/ Not Reproducible/ Need more information)

Must Read: Bug Life Cycle – Explained in detail

Description: In the description section, you must briefly explain what you have done before facing the bug.

Steps to reproduce: In this section, you should describe how to reproduce the bug in step by step manner. Easy to follow steps give room to the developers to fix the issue without any chaos. These steps should describe the bug well enough and allows developers to understand and act on the bug without discussing to the one who wrote the bug report. Start with “opening the application”, include “prerequisites” if any and write till the step which “causes the bug”.

Good:

i. Open URL “Your URL”
ii. Click on “Registration Page”
iii. Upload “JPEG” file in the profile photo field

Bad:

Upload a file in the registration page.

URL: Mention the URL of the application (If available)

Expected Result: What is the expected output from the application when you make an action which causes failure.

Good: A message should display “Profile picture uploaded successfully”

Bad: System should accept the profile picture.

Earlier I have posted a detailed post on “Test Case Template With Explanation”, if you haven’t gone through it, you can browse “Test Case Template With Explanation” here.

Actual Result: What is the expected output from the application when you make an action which causes failure.

Good: “Uploading a JPEG file (Profile Picture) in the Registration Page crashes the system”.

Bad: System is not accepting profile picture.