How to write bug report
In that article, you can find the answers to the questions: “how to write bug report”, “why bug report is so useful”, “where should create bug report”. We will touch the main aspects that you need to know in order to write effective and useful bug reports.
Why bug report is important
You just testing your project and test fail. My congratulation, you find a bug. Now you should report it.
In case if your bug report will be good on, it helps your developers to fix it and make the more reliable product.
How it helps developers exactly:
- tells about issues that they ain’t aware of
- helps determine new features that they may not have thought of
- helps get a feel as to how their customers use the software, so they can make it better
And if you write your bug report effectively then bug have more chances to be fixed. So fixing bugs are directly dependent on how you report it.
What is a good bug report
Anyone can write a bug report. But not everyone can do it effectively. You should be able to distinguish between a mediocre bug report and a good one. How to distinguish a good or bad bug report?
Useful bug reports are those that result in fixing that bug. A good bug report has to be:
- Reproducible – if reproduce the bug isn’t possible, then it won’t be fixed. As soon and easy as developer reproduce and see the bug, t it’ll be fixed. Otherwise, the more likely that the developer will simply proceed to the next bug report. In the description of the bug, you must to clearly describe the steps to reproduce without missing any of them.
- Specific and Informative – do not spread problem in the whole essay. Try to be specific and maximise informatively. Strive to summarize the problem in minimum words yet in an effective way. And in any case, don’t combine multiple problems even if they seem to be similar. Write different reports for each problem.
So the goals of a bug report are to:
- explain a bug to the developer and show where it is
- help the developer fix it with the minimal time cost
Content of bug report
Title: In title should be a short explanation of what the issue is. A good title should have information about product name or error message or steps you were doing when it failed.
- How not to do: “Crash”, “Looking an error”, “Bug”
- How to do: “Error 5C79 when confirming request”
Product: Specify the product name and version of which is operated.
- How not to do: “Your application”
- How to do: “Agfa”
Classification: Very important to indicate is this a feature request, minor bug or horrible bug that crash the whole application. Most of all tools have a set of these to choose from, but if they don’t, use on of this: “New feature”, “Minor Annoyance”, “Crashing Bug”, “Serious Bug” or “Minor Bug” for those you can work around.
- How not to do: “Leave it blank”
- How to do: “Serious Bug”, “Annoyance”, “Feature Request”
Platform: Will be a big plus to determine what you are using to run the software, particularly operating system name and version, in the case of Web Application, should tell web browser name and version. There are a lot of different versions of systems and browsers, which important to developers to know.
- How not to do: “Windows”
- How to do: “Windows 7, Internet Explorer 9”
Summary: Try to briefly describe what you were trying to do before you find the bug and how to react to this your application. Try to use simple natural language and write all simple sentences.
- How not to do: “Application don’t work”
- How to do: “Clicked on ‘File / Save As…’ and the ‘Save’ dialog came up →Cicked on the ‘OK’ button but the file did not save.”
Steps to reproduce: It’ll be great if you able to reproduce that bug again. Because of reproducible bugs easier to fix. You should describe how to reproduce that bug steps by step, as detailed as it possible. Don’t forget, you must be specific.
- How not to do: “
- Homepage >Left Button>Click on it
- Shop>try to buy smth>you can’t”
- How to do: “
- Go to Settings > Profile (this would take user to new screen)
- Tap on More Options > Delete Account”
Expected Result: What should happen when you make an action?
- How not to do: “I tried to print, but it didn’t work”
- How to do: “From the ‘Shop’ screen, click on the ‘Print’ button”
Actual Result: Here’s the result of the bug. As usual, testers are a little bit indefinite in this part of the bug report. So, try to be concise.
- How not to do: “Button does not work as expected”
- How to do: “Button closes app”
Priority: It’s showing to the developer how soon it has to be fixed. Priority is generally set from 1 to 5. The lower the number, the higher priority. 1 score – must be fixed as soon as possible. 5 score – can 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 a new feature or some enhancement in existing one.
Status: It’s showing the status of a bug report in any bug tracking system. At the beginning status of bug report will be “New”. After that status can changing like Fixed, Verified, Reopen, Won’t Fix and etc. All various statuses you will see below in Bug report life cycle
Attachments: If you can take a screenshot – do it. It’ll be a huge plus for developer see what you was seen before the bug and after. Just attach few screenshots for the bug report.
Here is an example of bug tracking system – EasyQA, which has all the necessary fields to write bug report.
Bug report life cycle
The bug report life cycle begins with the bug being detected and reported by the tester and ends after closure. Over the entire life cycle of the bug has different states.
The schematic life cycle can be shown on this graphic:
Bug life cycle includes following steps or status:
- New: When a bug is reported and posted for the first time. Its state is given as new.
- Assigned: After the tester has reported the bug, the lead of the tester confirm that the defect is valid and it assigned to the appropriate developer or developers team.
- Open: It means that the developer has begun to analyze the bug and trying to fix.
- Fixed: After developer changed the code and fixed bug, they change state to “Fixed” and it can be pass to QA team for retesting.
- Pending Retest: At this stage bug report waiting for retesting.
- Retest: At this stage, the testers check the amendments and retest the changing that developers have made.
- Verified: If retesting it isn’t detected the bug and the product is working properly, tester changes the bug report status in “Verified”.
- Reopen: Reopen: In case the tester rechecked and the bug still exists, the state of bug becoming “Reopen” and bug report goes through the life cycle once again.
- Closed: Once the developer has corrected the mistakes, he sends the product to testers for retesting. If the tester decides that the bug is fixed, he or she changes the bug report status to “Closed.” This means that the defect is fixed, checked and approved.
- Duplicate: If the bug is repeated twice or the two bugs mention the same concept of the bug, then one bug status is changed to “duplicate“.
- Rejected: If the developer feels that the bug is not genuine, he rejects the bug. Then the state of the bug is changed to “rejected”.
- Deferred: this means that the bug will be fixed, but in another release, and now it’s waiting. Usually, the reason for this is the low priority of bugs and lack of time.
- Not a bug: Bag report can have that status, in the case of, for example, if a customer asked to make any little changes to the product: change colour, font, and more.
Bug report writing tips
- What was happening before: To fix the bug developers need to reproduce all workflow that tester and system do. So, don’t forget to describe steps specifically and informatively.
- Be specific: You should write the same names of fields, buttons and other items as it named in the application. If you want to describe message, copy and paste the whole message in the description of the bug report.
- For menus: Follow the sequence of menus separated by the ‘/’ character, for example, “File / Save As…”
- For screens: Look at the top of the window and type exactly what is there
- For buttons or tabs: Copy and paste the exact text shown
- For links: Copy and paste the whole URL (including the “http://”)
- Don’t get personal: When you are reporting the bug, don’t forget, you reporting about the defect of software, not defect of the developer. Be polite and specific. Bug reports with offensive and emotional language will ignore by the developers.
- Attach or Copy and Paste: You should attach different screenshots, video, messages and etc as more as possible. It’ll help to developers easier and faster find the issue and fix it
- One defect per report: No more, no less. A single bug in a report can help to avoid duplication and confusion. If you describe too many defects some of them may be overlooked.
- Reproduce the bug before writing a bug report: Make sure your actions lead to reproducing the bug without ambiguity. The defect should be reproducible.
- Write a good summary: It will be easier for a developer to analyze bug nature. Poor defect reports waste testing and development time
I wish you will have only the great bug reports and in any case – don’t get upset. Everything comes with practice. So…