How to Report a Bug
What is bug report?
A report that describes the process to the futurity of the software in front of every member (basically
the programmers) is called a bug report. You may show to the programmers in person or give them
careful and detailed instructions on reproducing that. Simply, a bug report is the communicating way to
prove that the software has a failure case.
A bug report may contain the following sections to describe itself. It is just a best practice. There may be
more or less sections depending on project.
Bug Report:
Bug No: The bug number of the tracking system
Link: It is the public/private link of the bug
Bug Title : A title should describe the bug’s key point.(one line max)
Bug Summary : A summary should describe the full bug at a single line (Should not exceed one
line)
State: Any one of the bug states. (detail about those states in different post:
New/Open/Assign/Test/Verified/Deferred/Reopened/Duplicate/Rejected /Closed)
Prerequisites: The pre installed items/requirements should be here.
-Name of operating system (if it has dependency on different OS)
-Name of software installed (if it has dependency on software, Ex- Dot Net framework)
-Name of browser (if it has dependency on browser. Ex- Firefox, chrome, safari.)
-Hardware conditions & configurations (it it has dependency on different hardware)
Bug found version: The version no of the software in which the bug was founded
Bug fixing version: This is an optional tag describing which version will get the solve of the bug
(following project’s release plan)
Severity: The bug’s priority should be here. These are some priority tags. Those may be change
due to project scope. You may add priority value in there.
Blocker – blocks development and/or testing work (you probably wouldn't know)
Critical – crashes, loss of data (internally, not, say, your edit preview)
Major – major loss of function
Minor – minor loss of function or other problem where easy workaround is present
Trivial – cosmetic problem like misspelled words or misaligned text
Enhancement – request for enhancement (feature requests)
Reproducing steps: These are steps to reproduce the bug. Every step should be distinct. In here
a good tester will provide the shortest path to reproduce the bug.
Actual Value: The facts that found following the steps
Expected value: The results that was expected following the steps. It will be perfect to link up
the expected results with SRS/FRC documents.
Assign To: The responsible person who will take care of the bug.(initially, It may be assigned to
team leads, they may distribute the responsibility)
Reported by : Bug reporter's name
Comments: Comments which are very much welcomed in a bug life cycle. Any member or the
responsible person cans comments on that. It can be use for describing current state of the bug
in development lifecycle.
Attachments: Most of the bug trackers support multimedia attachments. If necessary, you may
attaché pictures, audio or even video. The best practice is to attaché picture (screen shots).
