Bug Report Template

Bug Report Template – 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.

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.

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

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)

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.

Attachments: Attach the screenshots which you had captured when you faced the bug. It helps the developers to see the bug which you have faced.

Defect Close Date: The ‘Defect Close Date’ is the date which needs to be updated once you ensure that the defect is not reproducible.

SAMPLE DEFECT/BUG REPORT TEMPLATE

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.

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: Date of the defect reported

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

How Detected: Testing, Review, Walkthrough

Project Name: Add name of the project. (If it’s a product, add product name)

Release/Build Version: Add the build version details here

Defect/Enhancement: Add whether it is defect or improvement

Environment: Add Operation Systems details, Browser Details and any other related to the test environment.

(E.g. Windows 8/Chrome 48.0.2564.103)

Priority: Add the priority of the bug

(E.g. High/Medium/Low)

Severity: Add the severity of the bug

(E.g. Critical/High/Medium/Low)

Status: Add the status of the bug. If you just found and posting it then it will be New. 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)

Description: Add a detailed description.

Steps to reproduce: Mention steps in detail. So that even the one who has no idea about the application also could reproduce the bug.

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

Expected Result: Mention the expected result here which is available in your test case document.

Actual Result: Mention the actual result here which is available in your test case document.

Defect Close Date: Add the defect close date only once you ensure that the defect is not reproducible.