Bug lists should be an important channel for testers and developers to communicate. Since communication is involved, there are communication costs.
We all want to communicate happily and efficiently with our developers. In order to communicate effectively, in addition to paying attention to language skills, the content description of the bug list also needs extra attention.
A, bug list
In fact, the main reason for making bug lists (defect reports) is to express the defects accurately and unambiguously through this document.
Developers can quickly understand defects and pinpoint problems based on defect reports. At the same time, through this defect report, the development manager can accurately estimate the priority of defect repair, and the product manager can understand the impact and severity of the defect to users or business.
In addition, the quality of defect reporting itself is directly related to the speed at which defects can be repaired and the efficiency of development engineers, as well as the credibility of testers and the effectiveness of test and development cooperation.
2. Content of efficient defect report
In our work, we usually use off-the-shelf tools such as JIRA, Bugzilla, BugFree, etc. These tools usually have a full set of features for defects that we can use right out of the box.
The tool just provides us some templates, how to fill in the specific content?
First, remember that a good defect report is never a stack of information, but rather provides accurate and useful information in an efficient way.
1. The title
The title is important as it is a general description of the defect. Also, the title is usually the first thing shown in the bug list. So try to:
1) Clear, concise and specific enough:
The defect title should not be too long. A more detailed description of the defect should be placed in the Defect Overview.
The usual form of the description can be: what went wrong under what circumstances.
Make sure the description is not too general, such as “there is a problem with the search function”. This description feels like nothing is said, and it can easily lead to resentment and resistance from developers.
In addition, the work of the tester also has an impact. For example, before you mention a bug, you want to check whether it has been mentioned by others, but the results are always in the form of titles. You have to check and confirm in details one by one, which also reduces our own work efficiency. It is estimated that their heart will be MMP, let alone development?
2) Describe the essence of the problem as far as possible and avoid staying on the surface of the problem:
The same sentence describes the problem, describing the surface and describing the essence, let people feel completely different:
- Description surface: commodity amount input box, you can input English letters and other characters.
- Description essence: commodity amount input box, no input content to do verification.
The second one seems the most intuitive.
2. Defect Overview
Defect overview is to refine the title and provide more general description of the nature and phenomenon of the defect.
The defect overview can also include other extensions of the defect, such as listing all possible scenarios for the same type of defect; For example, describe whether the same problem would recur in a previous release.
In summary, the purpose of a defect overview is to describe the defect clearly and concisely so that the developer can focus on the nature of the defect.
3. Impact of defects
If our testers want to accurately describe the impact of defects, they still need to have a deep understanding of the application scenarios and requirements of the software.
4. Preconditions
The goal is to reduce the description of defect recurrence steps.
For example, the precondition is that the user has logged in. There is no need to describe the login more than necessary in the next reproduction step.
5. Repeat the steps
Here comes the core.
Defect reappearance step is the core content of the whole defect report, which aims to show the specific operation steps of defect reappearance to the development engineer in concise language.
But before we do, we testers should make sure the problem is reproducible:
- Repeat multiple times.
- Find the shortest replay path and filter out unnecessary steps.
Next, it’s time to describe the reproduction steps, avoiding these three questions:
- Too general, lack of actionable steps.
- Steps that are not related to defect recurrence occur.
- Lack of description of test data.
6. Desired and actual results
The expected results come from an understanding of the requirements, and the actual results come from the results of test execution.
In a word: Should you say what happened, not what didn’t happen
7. Priority and severity
This is usually an option in the system.
Prior to this, we generally graded the priority and severity of the bug and synchronized it to the project members so that everyone could have a unified understanding of it.
The severity is the attribute of the defect itself, and usually will not change after the determination, while the priority is the engineering attribute of the defect, which will change with the project progress, the cost of solving the defect and other factors:
- The more serious the defect, the higher the priority.
- The greater the scope of the defect, the higher the priority.
- Defects that are not serious from a user impact perspective but hinder the execution of tests or automated tests are typically low in severity but high in priority.
- Some defects, although more serious, may be of lower priority due to repair costs and technical difficulties.
Also, check to see if there are workarounds for the problem.
Workarounds provide a way to temporarily work around a current defect without affecting product functionality. If so, it depends on how hard it is to implement.
If there are no workarounds available for a serious defect, the priority will be highest regardless of the cost of fixing the defect, but not necessarily if there is a simple workarounds for the defect.
8. Root cause analysis
Root cause analysis is the most able to reflect the tester’s personal ability and charm.
If you can identify the root cause of the problem as well as discover it, and then report back to developers, you will be much more effective at fixing defects and your technical impact will be recognized.
It’s not easy, though. A development background is usually required, or at least good code reading and debugging skills.
Therefore, to become a good tester, learning the mainstream development language is essential.
My personal recommendations are Python and Java. Because python is awesome for scripting. At present, the mainstream development language of most domestic companies is Java. Learning Java is to better understand the system you test and locate development problems.
Of course, to do root cause analysis needs to learn not only the language, but also the development framework (such as Springboot), the system architecture of the project, etc.
9. The attachment
Usually to provide necessary evidence to support the existence of defects, common attachments are interface screenshots, test case logs, server-side logs, GUI test execution videos, and so on.
Third, summary
Efficient bug lists, not necessarily in the form of the above, but the core content is the same.
As long as your report is quick and accurate to understand, it is a good report.
Reference: Software Testing 52 lecture by Ru Bingsheng