How to do best bug reporting?

Bug Reporting is an art of articulating all required steps to reproduce any found anomaly in any system. These anomalies might be any failure, fault or error in the behavior of feature in Test.

It means we have multiple questions that should be addressed first

Question 1: What is a bug

Question 2: How to report a bug

So let’s address the first question about Bug.

Bug: Bug in any software is defined as a fault, failure, error or anomaly that intends software in Test to produce an unexpected result which system was not supposed to deliver.

Once anomaly occurs. We need to report it and this reporting process which contains precise information about the bug is called Bug Reporting.

Bug reporting is an art and this can be honed through your effort to provide every single detail that can help the developer to fix a reported bug.
To make bug reporting a single source of truth that will be used by the developer to reproduce and fix it, bug reporter needs to provide the following details

Bug’s Unique ID: Every single logged defect/bug must have a unique id. But if you are using any defect/bug tracking tool, then don’t worry this will be the task of tool to assign unique number to newly raised bug.

Bug Summary: Every bug should have a precisely written summary which states the bug behaviour in a single line.
Let’s assume that when you clicking on submit button of any form on provided web application / mobile application, the system is crash. So this can be reported with the following bug summary.

System crashed when user clicking on submit button of <xyz> form

Build Version – Build detail is very important for any of the bugs raised to reproduce it.

Bug Description – This section is going to contain the following detail.
1- Steps to reproduce the bug.
2- Screenshots if any needed.
3- All system logs
4- Expected Result
5- Actual Result
and if you found any link which helps in fixing this bug technically. We should also add such resources. Because this can save the time of developer because he doesn’t search on the internet for a specific fix.

Date of bug reported: This will be automatically generated if team is using a bug tracking tool otherwise we need to add date for each bug.

Reference Document: Although such document is always placed on a common team location. From where anyone can refer to the requirement, design of the product. So if you want to add a specific section of such document then add it with the ticket.

Bug Reporter: Each bug should have reporter name/id.

Current Status: Status of any bug is very helpful to track the progress.

Assignee: Developer assigned to fix newly raise defect.

Environment/Platform: This section contains the environment used to detect bug (URL). Along with this if we are testing any web-application, in such case we should also specify the browser as well. But we are working on mobile application, in such case, we should provide the detail of the operating system (version for android/iOS).

Component: Product component where this defect has been found. This component information narrow down the assignee of the defect because in general, we all know which developer is working on which component.

Severity: This detail should be mentioned, how hard this bug is going to impact the current status of the product (Application). QA should add this with each reported bug.

Priority: Urgency to fix any of logged defect. Because of bug, companies face the loss of money and reputation in the market. So this is one factor which decides the tenure of a bug in the system.

We have seen all the information needed for good bug reporting. But there are a number of other good practices which should be followed by every QA during bug reporting.
1- Always check whether your bug is not duplicate. So we should make one practice to search a certain keyword in a database of bugs.
2- QA should mention how many time, he or she was able to reproduce this bug.
3- We should always try various steps to reproduce the same bug in the system. Because many a time bug is due to certain test data.
4- QA should always intimate respective developer about the bug or should discuss with the developer before raising any bug in the system.
5- It is imperative to be polite in writing.
6- If QA should always cc some of the relevant senior stack-holder.
7- QA should be optimistic that newly raised bug could be the inception of a new feature in the system.

The benefit of good bug reporting

1- This will reduce turn out time for any of the raised defect.
2- This will reduce conflicts between QA & Developer.
3- More and more bugs will be fixed without spending additional time by QA and Dev to reproduce it.
4- This increases the quality of the product with passes of time.
5- This will create a sense of ownership and will create a though among the team that Quality is everyone’s responsibility.
6- This will increase the trust of management in the team.

References:
1- Wikipedia.org
2- https://www.techopedia.com/