Scribd
Upload
139 views3 pages

Guide To Report A Bug

This document provides guidance on how to report a bug in software. It outlines the key elements that should be included in a bug report such as steps to reproduce the issue, expected vs. actual results, environment details and a severity rating. Reporters are instructed to write up the bug details in a structured document, save it in the appropriate folder and include things like the bug title, reproduction steps and visual proof if possible. This allows developers to efficiently understand and fix the problem.

Uploaded by

Syed Bahadur Ali Shah
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
139 views3 pages

Guide To Report A Bug

This document provides guidance on how to report a bug in software. It outlines the key elements that should be included in a bug report such as steps to reproduce the issue, expected vs. actual results, environment details and a severity rating. Reporters are instructed to write up the bug details in a structured document, save it in the appropriate folder and include things like the bug title, reproduction steps and visual proof if possible. This allows developers to efficiently understand and fix the problem.

Uploaded by

Syed Bahadur Ali Shah
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

Guide to report a Bug

A bug report should be able to answer the following questions:

● What is the problem?


● How can the developer reproduce the problem?
● Where has the problem appeared in the software?
● What is the environment (browser, device, OS) in which the problem has occurred?

Steps to Report a Bug:

● Write a report of the bug (Template of the report is placed in “Gapp Bugs” in Sharepoint
also Elements of the bug report are given below.).
● Name of the report file should be in BugID_title-of-the-bug.docx/pdf format.
● Save the bug report into the “Bugs” directory of “Gapp Bugs” in Sharepoint.

Elements of the Bug Report:

1. Title/Bug ID
2. Environment
3. Steps to reproduce a Bug
4. Expected Result
5. Actual Result
6. Visual Proof (optional)
7. 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”.
Assign an ID to the bug and set name of the file according to <Bug ID_Title>.docx.
2. 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. When reporting the bug, QAs must specify if the bug is observed in one or more
specific environments. Use the template below for specificity:

1. Device Type: Hardware and specific device model


2. OS: OS name and version
3. Tester: Name of the tester who identified the bug
4. Software version: The version of the software which is being tested, and in which the
bug has appeared.
5. 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-

1. Click “My Account” in the Navbar (this takes you to the User’s page).
2. Click on “Sign Out”.

4. Expected Result
How is the software supposed to work, with regard to the particular area in which the
bug appears?

5. Actual Result
Detail what the bug is doing, and how it is a distortion of the expected result. For
example “Link does not lead to the expected page. It shows a 404 error.”

6. Visual Proof of Bug


Attach visual proofs of the bug. it will help the developer to better understand the bug.

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


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

Levels of Bug Priority:


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.

Note:
Look for existing bug reports before reporting the bug to avoid redundancy.

You might also like