Effective Bug Report

An effective bug report should contain the following:

1. Bug ID
2. Title/Summary
3. Preconditions
4. Steps to reproduce
5. Actual Result
6. Expected Result
7. Attachments (visual proofs of bug such as screenshots, videos, logs)
8. Environment
9. Severity/Priority
10. Status
11. Date of creation
12. Additional information about a bug can be added if needed

Bug ID

Each bug should be given a unique identification number. Bug reporting tools automatically provide a unique number to the newly raised bugs. This field helps to identify the bug easily.

Title/Summary

A summary of the issue should be provided. The summary should be a concise statement that helps to identify the problem. Bug titles should be easy to understand, which would help identify the issue quickly. Try to briefly answer 3 questions: "What? Where? When?"

Preconditions

Provide the required setup or state before starting the main steps. This may include things like being logged in, having specific data created, or enabling a feature flag. Don’t skip this section even if some setup is also mentioned in the steps — clearly listing preconditions helps reproduce the bug correctly. Usually, they can be copied from the related test case.

Steps to reproduce

Steps are detailed instructions for the developer to follow in order to reproduce the bug. Just like assembling a chair purchased from the store, the instructions have to be in order and specific. If a step in the bug report is missing, there is a chance that the developer will not be able to reproduce the bug in order to fix it.

Here is an example:

Steps to reproduce:

1. Open https://bloomex.ca

2. Go to the “Lost password” page

3. Enter a valid email

4. Click on the “Send” button

Actual Result

Detail what the bug is actually doing, and how it is a distortion of the expected result.

Elaborate on the issue

Is the software crashing?

Is it simply pausing in action?

Does an error appear?

Or is it simply unresponsive?

Specificity in this section will be most helpful to developers. Emphasize distinctly on what is going wrong. Provide additional details so that they can start investigating the issue with all variables in mind. For example:

“Link does not lead to the expected page. It shows a 404 error.”

“When clicked, the button does not do anything at all.”

“The main image on the homepage is distorted on the iPhone X.”

Expected Result

Describe the expected result after performing the last step to reproduce the bug. Be specific and detailed about what should have happened if everything had worked correctly. Don’t just leave it at “the app is crashing, and it shouldn’t.”

Attachments (visual proofs of bug such as screenshots, videos, logs)

It is standard practice to attach files to bug reports because it's easier to perceive information when it is displayed visually.

For example:

- Screenshot (it's convenient when the bug is highlighted with a circle or an arrow)

- Video (sometimes it could be difficult to describe the bug in words, so it's better to see it for yourself)

- Log-file

Testing using BrowserStack can leverage multiple debugging options – text logs, visual logs (screenshots), video logs, console logs, and network logs. These make it easy for QAs and devs to detect exactly where the error has occurred, study the corresponding code and implement fixes.

Environment

A bug can appear in a particular environment and not others. For example, a bug appears when running the website on Firefox, or an app malfunctions only when running on an iPhone X. These bugs can only be identified with cross browser testing or cross device tests.

When reporting the bug that reproduces on specific environments QAs must specify it.

Severity/Priority

Every bug must be assigned a level of severity and corresponding priority. This reveals the extent to which the bug affects the system, and in turn, how quickly it needs to be fixed.

Levels of Bug Priority:

Low: Bug can be fixed at a later date. Other, more serious bugs take priority

Normal: Bug can be fixed in the normal course of development and testing.

High: Bug must be resolved at the earlier than task with less priority

Urgent: Bug must be resolved as soon as possible with current situation

Immediate: Bug must be resolved at the earliest as it affects the system adversely and renders it unusable until it is resolved.

Levels of Bug Severity (not necessary for now to note):

Low: Bug won’t result in any noticeable breakdown of the system

Minor: Results in some unexpected or undesired behavior, but not enough to disrupt system function

Major: Bug capable of collapsing large parts of the system

Critical: Bug capable of triggering complete system shutdown

Status

When a new defect is logged and posted for the first time. It is assigned a status as NEW.

In Progress - developer take bug to fix.

Test - bug is ready to test for QA.

Closed - bug fixed.

Date of creation

The date the bug report was created makes by the system automatically.

Additional information about a bug can be added if needed

Can mention about the other area when the same issue occur which helps developer fixes the bug completed

Example

ID	Created automatically by system
Summary	The "Order load error" is shown after scanning the QR code of the order by driver app
Precondition	Order was placed
Steps to reproduce	1. Go to https://new-driver.bloomex.ca 2. Login (with credentials of a driver with the same warehouse as the order) 3. Tap on the scan button 4. Navigate to QR code of the order 5. Pay attention at the error
Actual Result	The "Order load error" is shown after scanning the QR code of the order
Expected Result	The QR code was scanned successfully and the order was identified to add to the route
Attachment
Environment	Poco F2 Pro (Android v. 11)
Priority	Immediate
Status	New
Date of creation	Created automatically by system