Here’s how to write a good bug report with some helpful tips and tricks. Let’s get started.
“The point of writing a problem report (bug report) is to get bugs fixed” – Cem Kaner.
If a tester is not reporting a bug correctly, then the programmer will most likely reject it stating it as irreproducible. This can hurt the tester’s morals and sometimes ego as well.
If the Bug report is effective, then its chances of getting fixed are higher. So fixing a bug depends upon how effectively you report it. Reporting a bug is nothing but a skill and in this tutorial, we will explain how to achieve this skill.
How To Write A Good Bug Report
IMG-1
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 between a good and bad Bug report? It’s very simple, apply the following characteristics and techniques to report a bug.
Characteristics and Techniques
1) Having a clearly specified Bug Number: Always assign a unique number to each bug report. This will help you identify the bug record. If you are using an automated bug-reporting tool then this unique number will be generated automatically each time you report a bug.
Note the number and a brief description of each bug that you reported.
2) Reproducible: 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 steps. The bug which is described step by step 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.
Effective Bug Reporting
Bug reporting is an important aspect of Software Testing. Effective Bug reports communicate well with the development team to avoid any confusion or miscommunication.
Good Bug report should be clear and concise without any missing key points. Any lack of clarity can lead to misunderstandings and slows down the development process as well. Defect writing and reporting is one of the most important but neglected areas in the testing life cycle.
Good writing is very important for filing a bug. The most important point that a tester should keep in mind is not to use an authoritative tone in the report. This breaks morale and creates an unhealthy work relationship. Use a suggestive tone.
Don’t assume that since the developer has made a mistake, you can use harsh words. Before reporting, it is equally important to check if the same bug has been reported or not.
A duplicate bug is a burden in the testing cycle. Check out the whole list of known bugs. At times, the developers may be aware of the issue and ignore it for future releases.
Tools like Bugzilla, which automatically searches for duplicate bugs, can also be used. However, it is best to manually search for any duplicate bug.
The important information that a bug report must communicate is “How?” and “Where?” The report should clearly answer how the test was performed and where the defect occurred. The reader should easily reproduce the bug and find out where the bug is.
Keep in mind that the objective of writing a bug report is to enable the developer to visualize the problem. He/She should clearly understand the defect from the Bug report. Remember to provide all the relevant information that developers seek.
It should also be noted that bug reports will be preserved for future use and should be well-written with the required information. Use meaningful sentences and simple words to describe your bugs. Don’t use confusing statements that will waste the time of the reviewer.
Report each bug as a separate issue. In case of multiple issues in a single bug report, you can’t close it unless all the issues are resolved.
Hence, it is best to split the issues into separate bugs. This ensures that each bug can be handled separately. A well-written bug report helps a developer to reproduce the bug at their terminal. This will help them diagnose the issue as well.
How To Report A Bug
Use the following simple Bug report template:
This is a simple Bug report format. It may vary depending on the Bug report tool that you are using. If you are writing a bug report manually then some fields need to be mentioned specifically like the Bug number, which should be assigned manually.
Reporter: Your name and email address.
Product: In which product did you find 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, and Mac OS. Also, mention the different OS versions like Windows NT, Windows 2000, Windows XP, etc., if applicable.
Priority: When should a bug be fixed? Priority is generally set from P1 to P5. P1 as “fix the bug with the highest priority” and P5 as ” Fix when time permits”.
Severity: 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 a new feature or some enhancement in the existing one.
Status: When you are logging the bug into any bug tracking system then by default the bug status will be ‘New’.
Later on, the bug goes through various stages like Fixed, Verified, Reopened, Won’t Fix, etc.
Assign To: If you know which developer is responsible for that particular module in which the bug occurred, then you can specify the email address of that developer.
Otherwise, keep it blank as this will assign the bug to the module owner. If not, the Manager will assign the bug to the developer. Possibly add the manager’s email address to the CC list.
URL: The page URL on which the bug occurred.
Summary: A brief summary of the bug, mostly within 60 words or below. Make sure your summary is reflecting on what the problem is and where it is.
Description: A detailed description of the bug.
Use the following fields for the description field:
Reproduce steps: Clearly, mention the steps to reproduce the bug.
Expected result: How the application should behave on the above-mentioned steps.
Actual result: What is the actual result of running the above steps i.e. the bug behavior?
These are the important steps in the bug report. You can also add “Report Type” as one more field which will describe the bug type.
Report Types include:
1) Coding error
2) Design error
3) New Suggestion
4) Documentation issue
5) Hardware problem
Important Features in Your Bug Report
Given below are a few important features in the Bug report:
1) Bug Number/id
A Bug number or an identification number (like swb001) makes bug reporting and the process of referring to bugs much easier. The developer can easily check if a particular bug has been fixed or not. It makes the whole testing and retesting process smoother and easier.
2) Bug Title
Bug titles are read more often than any other part of the bug report. This should explain everything about what comes with the bug.
The Bug title should be suggestive enough that the reader can understand it. A clear bug title makes it easy to understand and the reader can know if the bug has been reported earlier or has been fixed.
3) Priority
Based on the severity of the bug, a priority can be set for it. A bug can be a Blocker, Critical, Major, Minor, Trivial, or a suggestion. Bug priorities can be given from P1 to P5 so that the important ones are viewed first.
4) Platform/Environment
OS and browser configuration is necessary for a clear bug report. It is an effective way to communicate how the bug can be reproduced.
Without the exact platform or environment, the application may behave differently and the bug at the tester’s end may not replicate on the developer’s end. So it is best to clearly mention the environment in which the bug was detected.
5) Description
Bug description helps the developer to understand the bug. It describes the problem encountered. A poor description will create confusion and waste the time of the developers as well as testers.
It is necessary to communicate clearly the effect of the description. It’s always helpful to use complete sentences. It is a good practice to describe each problem separately instead of crumbling them altogether. Don’t use terms like “I think” or “I believe”.
6) Steps to Reproduce
The Bug report should clearly mention the steps to reproduce. These steps should include actions that may cause the bug. Don’t make generic statements. Be specific on the steps to follow.
A good example of a well-written procedure is given below
Steps
Select product Abc01.
Click on Add to cart.
Click Remove to remove the product from the cart.
7) Expected and Actual Results
A Bug description is incomplete without the Expected and Actual results. It is necessary to outline what the outcome of the test is and what the user should expect.
The reader should know what the correct outcome of the test is. Mention clearly what happened during the test and what the outcome was.
8) Screenshot
A picture is worth a thousand words. Take a Screenshot of the instance of failure with proper captioning to highlight the defect. Highlight unexpected error messages with light red color. This draws attention to the required area.
Some Bonus Tips To Write A Good Bug Report
Given below are some additional tips on how to write a good Bug report:
1) Report the problem immediately
If you find any bugs while testing, then you do not need to wait to write a detailed bug report later. Instead, write a bug report immediately. This will ensure an effective Bug report.
If you decide to file a Bug report later on then there is a higher chance that you will miss the important steps in your report.
2) Reproduce the bug three times before writing a 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, then you can still file a bug mentioning the periodic nature of the bug.
3) Test the same bug occurrence on other similar modules
Sometimes the developer uses the same code for different similar modules. So there is a higher chance for the bug in one module to occur in other similar modules as well. You can even try to find the more severe version of the bug you found.
4) Write a good bug summary
Bug summary will help the developers to quickly analyze the bug’s nature. Poor-quality reports will unnecessarily increase development and testing time.
Communicate well with your bug report summary. Keep in mind that the bug summary can be used as a reference to search for the bug in the bug inventory.
5) Read the Bug report before hitting the Submit button
Read all the sentences, wordings, and steps that are 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 good work and found a bug but do not use this credit for criticizing the developer or attacking any individual.
Conclusion
There is no doubt that your bug report should be a high-quality document.
Focus on writing good bug reports because this is the main communication point between the tester, developer, and manager. Managers should create an awareness in their team that writing a good bug report is the primary responsibility of any tester.
Your effort toward writing an effective 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, make sure to write an effective bug report.
if u need more help please contact us at +91- 93 92 91 89 89 or sales@qaprogrammer.com, www.qaprogrammer.com
Share on: