Why good Bug report?
If your bug report is effective, then its chances are higher to get fixed. So fixing a bug depends on how effectively you report it. Reporting a bug is nothing but a skill and I will explain you how to achieve this skill.
“The point of writing problem report(bug report) is to get bugs fixed” – By Cem Kaner. If a tester is not reporting bug correctly, programmer will most likely reject this bug stating as irreproducible. This can hurt testers moral and some time ego also. (I suggest not to keep any type of ego. Ego’s like “I have reported bug correctly”, “I can reproduce it”, “Why he/she has rejected the bug?”, “It’s not my fault” etc etc..)
What are the qualities of a good software bug report?
Anyone can write a bug report. But not everyone can write an effective bug report. You should be able to distinguish between an average bug report and a good bug report. How to distinguish a good or bad bug report? It’s very simple, apply the following characteristics and techniques to report a bug.
#1) Having a clearly specified bug number:
Always assign a unique number to each bug report. This will help you to identify the bug record. If you are using any automated bug-reporting tool then this unique number will be generated automatically each time you report the bug. Note the number and brief description of each bug you reported.
If your bug is not reproducible, then it will never get fixed. You should clearly mention the steps to reproduce the bug. Do not assume or skip any reproducing step. Step by step described bug problem is easy to reproduce and fix.
#3) Be Specific:
Do not write an essay about the problem. Be Specific and to the point. Try to summarize the problem in minimum words yet in an effective way. Do not combine multiple problems even if they seem to be similar. Write different reports for each problem.
How to Report a Bug?
Use the following simple Bug report template:
This is a simple bug report format. It may vary depending upon the bug report tool that you are using. If you are writing a bug report manually then some fields need to be specifically mentioned like Bug number which should be assigned manually.
Reporter: Your name and email address.
Product: In which product you found this bug.
Version: The product version if any.
Component: These are the major sub modules of the product.
Platform: Mention the hardware platform where you found this bug. The various platforms like ‘PC’, ‘MAC’, ‘HP’, ‘Sun’ etc.
Operating system: Mention all the operating systems where you found the bug. Operating systems like Windows, Linux, Unix, SunOS, Mac OS. Mention the different OS versions also if applicable like Windows NT, Windows 2000, Windows XP etc.
When bug should be fixed? Priority is generally set from P1 to P5. P1 as “fix the bug with highest priority” and P5 as ” Fix when time permits”.
This describes the impact of the bug.
Types of Severity:
- 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: Some UI enhancements.
- Enhancement: Request for new feature or some enhancement in existing one.
When you are logging the bug into any bug tracking system then by default the bug status is ‘New’.
Later on the bug goes through various stages like Fixed, Verified, Reopen, Won’t Fix etc.
Click here to read more about detail bug life cycle.
If you know which developer is responsible for that particular module in which bug occurred, then you can specify the email address of that developer. Else keep it blank this will assign bug to the module owner or the Manger will assign bug to the developer. Possibly add the manager email address in CC list.
The page URL on which bug occurred.
A brief summary of the bug mostly in 60 words or below. Make sure your summary is reflecting what the problem is and where it is.
A detailed description of the bug. Use following fields for description field:
- Reproduce steps: Clearly mention the steps to reproduce the bug.
- Expected result: How application should behave on the above mentioned steps.
- Actual result: What is the actual result on running the above steps i.e. the bug behavior.
These are the important steps in bug report. You can also add the “Report type” as one more field which will describe the bug type.
The report types include:
1) Coding error
2) Design error
3) New suggestion
4) Documentation issue
5) Hardware problem
Some Bonus tips to write a good bug report:
1) Report the problem immediately:If you found any bug while testing, do not wait to write a detail bug report later. Instead write the bug report immediately. This will ensure a good and reproducible bug report. If you decide to write the bug report later on then are higher chances to miss the important steps in your report.
2) Reproduce the bug three times before writing bug report:Your bug should be reproducible. Make sure that your steps are robust enough to reproduce the bug without any ambiguity. If your bug is not reproducible every time you can still file a bug mentioning the periodic nature of the bug.
3) Test the same bug occurrence on other similar module:
Sometimes developer use the same code for different similar modules. So chances are high that the bug in one module can occur in other similar modules as well. You can even try to find more severe version of the bug you found.
4) Write a good bug summary:
Bug summary will help developers to quickly analyze the bug nature. Poor quality report will unnecessarily increase the development and testing time. Communicate well through your bug report summary. Keep in mind that the bug summary is used as a reference to search the bug in bug inventory.
5) Read bug report before hitting Submit button:
Read all the sentences, wordings, steps used in the bug report. See if any sentence is creating ambiguity that can lead to misinterpretation. Misleading words or sentences should be avoided in order to have a clear bug report.
6) Do not use Abusive language:
It’s nice that you did a good work and found a bug but do not use this credit for criticizing developer or to attack any individual.
No doubt that your bug report should be a high quality document. Focus on writing good bug reports and spend some time on this task because this is the main communication point between tester, developer and manager. Mangers should create awareness to their team that writing a good bug report is the primary responsibility of any tester. Your effort towards writing a good bug report will not only save the resources of the company but also create a good relationship between you and the developers.
For better productivity write a better bug report.