Good Bug Report

Bug Report

It is the main interface of the technical team to the world of defects/ bugs/ deviations.

Why do you require a good bug report?
A good bug report is required in order to let know the technical team that there exists deviations in the application/ module/ system.

What is a good bug report?
- A bug report is said to be good, if it is effective.
- Effective necessarily means that the bugs will definitely be fixed, because the technical team has understood what is written in the bug report.
- Understanding what is written means that the chance of fixing are HIGHER.


Typical scenarios involving an inappropriate/ incomplete/ ineffective bug report.
- Suppose the tester does not report the bugs in the appropriate manner, chances are
a) Programmer will most likely reject the bug (because they haven't understood anything). The bug can be set as IRREPRODUCIBLE.
b) We will lose valuable time in trying to explain to the developer. By that time, we would have forgotten the scenarios that led to the bug.


Characteristics/ Features of a Bug report

1) A bug should have a unique bug id
- Every bug should have a unique number associated to it. THis will help in indentifying the bug record/ details.
- In the case of an automated tool being used for recording defects/ bugs, the tool will generate the unique bug id.


2) The bug to be explained specific to the problem at hand- A typical mistake made by the testers is to write an essay/ paragraph to explain the bug.
- You should try to explain in points
- Be very specific and to the point in explaining the bug in the related scenarios.
- The summary to the bug should be less than or equals 100 characters and should not exceed a sentence. It should be summarized within a sentence and that too effectively too.
- Do not link and write about two bugs in the same description even though they are related to the same scenario or seem to be similar.

3) The bug should be reproducible- Remember that if the bug is not Reproducible then it will never be fixed.
- Indicate with a separate section called "Steps to Recreate".
- Never, Never skip any step assuming that the technical team will understand the step no matter how trivial the step is.


A typical Bug Report template
Bug ID : [A unique number associated to the bug]
Reporter: [Your name] [email address to ease the feedback and communication]

Product: [The related product in which the bug was found]

Version: [The version of the product]

Component: [It could be related to submodules/ subsections, whichever applicable to your application]

Platform: [Indicate the platform if you are involved in multi-platform testing] E.g. Desktop, Server. etc.

Operating system: [Indicate the operation system] E.g. Windows, Linux, Unix. etc.

Priority: [An indication of when the bug should be fixed. It is set typically from P1 to P5 with P1 as the highest priority and to be fixed asap and P5 with the lowest priority]

Severity: [Indicating how severe the bug is]
Typical severity levels are
- Blocker: No further testing work can be done.
- Critical: Application crash, Loss of data.
- Major: Major loss of function.
- Minor: minor loss of function.
- Trivial/ Low: UI enhancements, typographical mistakes
- Enhancement: Request for new feature or few enhancements in existing application.

Status: [indicates the status of the bug as it travels through the defect workflow]

Typical Status levels are- New
- Fixed
- Verified
- ReOpened
- Won't Fix
- Future Fix
- Duplicate etc.

Assign To: [The person to whom the bug is assigned to for work, rework, resolution, closue etc.]

URL:[The URL on which the bug was found]

Summary: [A brief summary of the bug]

Characteristics of the summary are
- Should be utmost 100 characters or less.
- It clearly indicates the problem
- having it less than 60 characters makes a lot of sense, since it is easily comprehensible.

Description: [Detailed description of the bug]
It should include
- An expanded summary line
- Steps to Recreate : show the steps correctly in sequence and clear to understand.
- Expected REsult : Illustrate the expected behavior of the application
- Actual Result : What did you find in the current scenario. In short it is the bug behavior.

Bug Type : [Indicates the type of the bug]
Typical bug types are
- Coding error
- Design error
- New Feature
- Documentation
- Hardware problem
- Rework


Tips to write a good bug report
1) Wring the bug report immediately
The moment you find the bug, do write it immediately. If you plan to write it later, chances are that you will forget some of the detailed steps that you had undertaken in order to find the bug.

2) Try to reproduce the bug atleast thrice before writing the bug report
You should make it a habit to try and reproduce the bug atleast thrice before you report it. If you find that the bug is not reproducible, then chances are that it may or may not get fixed.

3) Do test the same bug to verify if it appears in other related or similar module
Most developers use the same code in different modules , which may be related to each other. So there is every possibility that the bug could occur in all such modules.


4) Have a very good bug summary
A bug summary will enable the technical team to identify the bug and understand it. They will be able to easily comprehend the deviation and identify the root cause related to the bug. Having a good bug summary eases the difficulty encountered in trying to understand the bug and it also aids in fixing the bug earlier. In the long run, it reduces the development and testing time.

5) Do not use a degrading language in your bug report.
- Never ever point accussing fingers through your bug report.
- Never discredit a developer/ programmer.

6) Always read the entire bug report before submitting
- Remove sentences that create ambiguity and hence misinterpretation.
- read the entire bug report to verify if it makes sense to you.
- If possible, ask your neighbour to read the bug report and ask her/ him their interpretation of the report.


Summary - A bug report should be easy to understand, clear, and to the point
- It is the main interface of the technical team to the world of deviations.
- The tester should take it as a prime responsibility to write a good bug report.
- A good report will reduce development and testing time considerably.


Example of a Bug Report.
Defect ID :947
Status : Open
Severity : Medium

Summary :
User Account : Script Error encountered when the user tries to create an user account

Description
When the user tries to create an user account from the login screen, a script error is encountered.

Steps to recreate
1) Invoke the login page.
2) Click Create User available at the bottom of the page.
3) The user will be navigated to a user account creation page.
4) Enter relevant details for the user.
5) Click the checkbox for the label "I agree to the terms of use and privacy policy".
6) Note the script error that comes up.

Please refer to the attachment.

Expected Result : The user should be able to successfully create an user account.

Actual result : The user encounters a script error when trying to create an user account.

Snapshots (if any).