Among all things related to testing, bug reports are something that a tester faces daily. These documents describe a bug, its severity and priority, and the steps to reproduce it. Based on bug reports, developers can quickly determine which part of the code is not working correctly and fix it.
A well-written bug report guarantees effective collaboration between the development and test teams. Therefore, the ability to write bug reports is one of the most important skills of a tester.
Why We Need Bug Reports
Why can we not fix bugs right away? Why do you need to write reports? Writing bug reports is essential because:
1. There is documentation on the existence of a bug.
There is a report—there is a record of the issue. You should not write bugs in Skype/chat/speak in person, etc. There is a chance that someone will forget about it (including you) and not fix it. Then the bug will be found either by the customer during acceptance testing or by the client, and they are unlikely to be happy about it.
2. Bug reports help the developer.
To reproduce and then fix the bug, the developers need information. Bug reports should be as accurate, complete, and understandable as possible. Without complete documentation, the developer will have to spend time searching for and analyzing the error.
3. It becomes possible to prioritize fixes.
If you have several bugs, you will always have to choose which one to fix first because you will not be able to fix everything at once.
4. It becomes possible to analyze errors.
Having information about defects lets you determine root causes and make changes to work processes to prevent errors.
5. The tester contributes to fixing the bug.
A well-crafted bug report is a huge help to the developers because it lets them quickly determine where the error is and fix it.
6. It becomes possible to control at which stage you fix the bug.
You already know that before it is fixed, each bug goes through certain stages of its life cycle. The presence of a defect report with a changing status allows you to quickly and easily determine the exact "position" of the bug and control its correction.
7. It becomes possible to assess the current quality of the product.
Suppose, during testing, 50 bugs were found, and all of them were filed as bug reports. As a manager, you will be able to evaluate the product's readiness, assess the number of required improvements, make decisions about the release, etc. Defect reports provide teams with beneficial and essential information to control product quality.
That is why the skill of writing good reports is critically important for any professional tester and must be mastered.
Steps to Writing a Bug Report
The bug report is entered into the bug tracking system (Jira, Trello). It consists of a title, description, and several fields (associated tasks, team, designer, tags, priority) that are filled or not filled depending on the project.
The title should be short and descriptive. The essence of the problem should be made clear in the title. Usually, the title is compiled according to the principle "What? Where? When?". For example:
What – Opens an empty dropdown
Where – on the main page
When – by clicking on it.
The description of a bug report may differ from project to project, but here are the general sections:
1. A more detailed description of the problem than in the title.
2. Description of the initial state of the system and other data about the environment:
- The browser and its version
- Test environment: dev, stage, prod
- The device on which the test took place: mobile phone, tablet, desktop with their operating system
3. Steps to reproduce the error.
All verbs are written in the infinitive. No need to write "I pressed the button." It would be more correct to write "click on the button" / "open the basket" / "home page." The steps are numbered. If you need to open a third-party resource, attach a link in brackets.
4. Describe the actual result.
Include the text plus a screenshot or recorded video. The video should be recorded without extraneous sound unless a program component is tested that involves sound. Other background noises can be distracting and annoying. If the video is large or there is no way to attach it directly to the bug tracking system, you can upload it to Google Drive and paste a link to it (always check the link and permissions before pasting).
When inserting a screenshot, you must first mark the error. Surround it with a rectangle of a highlight color—red is customary. You can describe the expected result next, right on the photo.
If there is any input data, be sure to register it. If the amount is incorrectly calculated, then provide the data for the numbers used. If a field is not validated correctly, give the data used when filling it out.
5. Describe the expected result.
Include text or a screenshot (if we are talking about a UI bug) of the requirements. Sometimes, you can combine the actual and expected results in one photo for clarity. A single photo is easier for the developer to navigate as there is no need to flip the images back and forth.
6. Set priority and severity.
"Priority" and "severity" are usually displayed in dropdown lists separate from the description. These are set by the tester but can be corrected later by the developer or PM.
Priority:
- P1 High (urgent)
- P2 Medium (can wait)
- P3 Low (not urgent)
Severity:
- Blocker (disrupts performance)
- Critical (affects significantly)
- Major (distorts the displayed information but does not bring noticeable changes)
- Minor (does not affect the operation of the program)
7. Assign to the developer or PM.
8. Click "done." :)
The Life Cycle of a Bug Report
- Open (Open) – you created a bug report and handed it over to the developer/PM (so that PM can issue it to a developer). The bug may go to the backlog, a special place where bugs wait to be selected and sent to development. It is like players on the bench waiting for their chance to play.
- In Work (In Progress) – the bug is transferred to the developer to fix it.
- Fixed (Ready for Design/QA) – the developer fixed the bug and submitted to the designer (if one is on the team) or tester for re-checking. If the bug turns out to be unfixed, it is returned to the developer (it is advisable to attach a photo/video report that the bug is still displayed).
- Closed – the bug has been verified and is no longer reproduced. When closing a bug, the tester writes in the comments on which environment it was tested and attaches a screenshot or video that the bug is really fixed. This last action confirms that the bug was fixed if it appears again later and questions arise.
Main Mistakes When Writing Bug Reports
1. Title that is incomprehensible or too long.
You have to read it several times to get a general idea.
2. Not enough data in the description or missing screenshots.
Such a bug report will be sent back and forth from the developer to the tester, or the developer will need to take a long time to find all the necessary data. Therefore, it is key to write a detailed bug report initially.
3. Bug reports are repeated.
If there is more than one tester on the project, you should check if it is the same bug report.
4. One problem, one report.
It is not necessary to insert many different errors into one report if they are not related to each other.
5. The expected result links the requirements without specifying the exact section.
The developer will waste time reading the entire document (or will send the bug report back to you). When attaching the requirements, it is necessary to indicate which section and paragraph to find the essential information. If the conditions require only a couple of lines, attach a photo of these lines. This will save the developer time as it will not be necessary to download and flip through the entire document.
In Conclusion
If your bug report is written correctly, the chances of quickly fixing a bug are higher. Thus, fixing a bug depends on how well you report it. The point of writing a bug report is to fix problems. Therefore, writing proper bug reports is an essential skill and needs to be developed.