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

  1.  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.
  2. 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.
  3.  Steps to Reproduce a Bug: Number the steps clearly from first to last so that the developers can quickly and exactly follow them to see the bug for themselves. Here is an example of how one can reproduce a bug in steps:
    • Click on the “Add to Cart” button on the Homepage (this takes the user to the Cart).
    • Check if the same product is added to the cart.

  4.  Expected Result : This component of Bug Report describes how the software is supposed to function in the given scenario. The developer gets to know what the requirement is from the expected results. This helps them gauge the extent to which the bug is disrupting the user experience.

    Describe the ideal end-user scenario, and try to offer as much detail as possible. For the above example, the expected result should be:

    “The selected product should be visible in the cart.”

  5.  Actual Result

    • Elaborate on the issue
    • Is the software crashing?
    • Is it simply pausing in action?
    • Does an error appear?
    • Or is it simply unresponsive?

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

  6. Visual Proof of Bug

    Screenshots, videos of log files must be attached to clearly depict the occurrence of the bug. Depending on the nature of the bug, the developer may need video, text, and images.

    Testing using BrowserStack can leverage multiple debugging options such as 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.

    BrowserStack’s debugging toolkit makes it possible to easily verify, debug and fix different aspects of software quality, from UI functionality and usability to performance and network consumption.

  7.  Bug Severity/Priority

    • 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
    • Low: Bug can be fixed at a later date. Other, more serious bugs take priority
    • Medium: Bug can be fixed in the normal course of development and testing.
    • High: Bug must be resolved at the earliest as it affects the system adversely and renders it unusable until it is resolved.

    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 Severity:

    Levels of Bug Priority:


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