How to log a defect/bug with a detailed description etc?

 Effectively reporting a bug is essential for the development team to resolve the issue promptly and accurately. A well-constructed bug report should be concise, comprehensive, and comprehensible. 

The following steps can be taken to submit a bug report:

  1. Attempt to replicate the bug consistently and systematically.
  1. Gather data on the environment, such as the browser type, operating system, and applicable software versions.
  1. Construct explicit instructions outlining how to reproduce the bug.
  1. Include screenshots or videos that may assist in illustrating the issue to developers.
  1. Articulate what outcome was anticipated and differentiate it from what occurred in reality.
  1. Outline the severity and priority of the bug: Describe how the bug impacts the software’s functionality and determine its level of urgency.
  1. Check for duplicates: Investigate the bug tracking system to ascertain if it has already been reported.
  1. Assign the bug to a relevant developer or team and follow up
  1. Monitor progress on the bug to ensure it is being addressed and provide any extra information that may be necessary.
Essential Features in Bug Report :

Various bug reporting tools, like Jira, Bugzilla, Excel or Word can also be used for reporting bugs for small projects. Irrespective of the tools used for logging the bug, the tester must capture some details in the bug report.

Below are the essential details that should be mentioned while creating a bug report:

  1. 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.
  2.  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.A good bug summary helps managers review the bugs quickly during the bug review meetings.
  3.  Description:The description should be provided in the bug to help the developer in understanding the bug. It should be in simple language that a developer can understand easily.All the details about the environment and the type of user privileges must be mentioned. For eg. any prerequisite for executing test steps like any configuration or test data.Let’s look at another example: the Mobile app crashes while switching to a module to which the user can’t access. In these scenarios, user privileges details must be mentioned in the prerequisite along with the URL of the admin page to modify the user permissions
  4.  Test Steps: Test steps are a detailed description of the exact steps taken to replicate an issue and should be included when reporting a problem. They provide the necessary information for developers to identify and debug any issues. Test steps should be written clearly and concisely, outlining each step in detail so that it can be easily followed by the developer.
  5.  Actual Results: The actual result of the test steps must be mentioned. Regardless of the outcome, documenting what happened to conclude the result will help improve future scenarios.
  6.  Expected Results: Expected results corresponding to failed steps must be mentioned, which would help the developer to know the exact behavior to adapt while fixing the bug. This section will also be helpful while retesting the bug.
  7.  Reporter:The name and email of the reporter of the bug should be mentioned. In bug reporting tools, these are automatically fetched from the user profile. It would help the developer or reviewer to quickly identify who reported the bug. Developers can reach out to the reporter if any discussion is required around the bug.
  8.  Reported date:The date when the bug is raised should be mentioned. This will help in identifying the release in which the bug occurred.

 Assignee:The bug should be assigned to the product owner or development manager. They can review the bug and plan the fix as per the team member’s bandwidth and module expertise. In some cases, bugs can be left unassigned and added to the bugs queue, where developers can pick them according to priority.

10. Severity:The tester defines it for bugs depending upon the impact on the application. Severity can be as follows:i. Blocker: Blocks development and/or testing work and/or the actual use of the system/product (e.g. crash upon starting the app)ii. Major: Major loss of function, with no workaround, other parts of the product/system still workiii. Normal: Normal loss of function, or other problem, where a difficult workaround is presentiv. Minor: Minor loss of function or other problem where a workaround is present for the functionality

11. Priority:It is defined as a bug by the tester/product owner, considering severity, probability, business needs, time, and resources available.i. Critical: Bugs that are mission-critical to the application’s core functionality and for which there are no workarounds.Note: These bugs should be sporadic, and this category should only be used if encountering a team/user blocking situation.ii. Urgent: Bugs related to the application’s core functionality and have to be fixed urgently within the sprint.iii. High: Bugs that do not affect critical user functionality and have workarounds. These bugs can be fixed in the next sprint.iv. Normal: Bugs that do not interfere with core functionality are just annoyances that may or may not ever be fixed.v. Low: Whatever gets defined as low might be kept in the backlog and might be closed as a known issue.

12. Status: A software bug follows a cycle. According to where it is in the cycle, a status is assigned. For eg. When a new bug is created, its status is assigned as open. Later, it goes through various stages like In Progress, Fixed, Won’t Fix, Accepted, Reopen, Verified, etc. These stages vary following different bug reporting tools.


Comments

Post a Comment

Popular posts from this blog

What is a client and a server?

  According to  a client-server architecture, clients request services from a server. Servers provide the requested service to their clients. However, clients and servers are separate programs running on different machines.  Clients act as the front end, and servers remain at the back end. Clients are in charge of delivering the user with data, whereas servers are in charge of storing and managing the data. The definition of a Client is as below:- A computer device that asks a server for services is known as a customer. The customer is the front-end element in client and server architecture which communicates with the user and sends requests to the server. Some examples are  laptops, desktops, etc. The definition of  a Server is as below:- A server offers services to other devices connected to a network. A server's primary functions include accepting and completing customer requests as well as storing and managing data. Some examples are  web servers, datab...
Read more

Why is it important to have a detailed bug description with evidence?

An effective bug report should contain the following: Title/Bug ID Environment Steps to Reproduce a Bug Expected Result Actual Result Visual Proof (screenshots, videos, text) of Bug Severity/Priority  Title/Bug ID:  The title should provide a quick description of the bug. For example, “ Distorted Text in FAQ section on <name> homepage ”. Assigning an ID to the bug also helps to make identification easier. Environment: Device Type : Hardware and specific device model. OS: OS name and version. Tester: Name of the tester who identified the bug. Software Version: The version of the software which is being tested, and in which the bug has appeared. Connection strength:If the bug is dependent on the internet connection (4G, 3G, WiFi, Ethernet) mention its strength at the time of testing. Rate of reproduction:The number of times the bug has been reproduced, with the exact steps involved in each reproduction.  Steps to Reproduce a Bug:  Number the steps clear...
Read more