How to efficiently raise valuable defects?#
1. When should defects/issues/bugs be raised?#
- When the functionality does not meet the requirements or there is a technical issue.
- When the problem cannot be solved by oneself or within the team and requires cross-department communication or support.
- When it exposes process or management issues.
- When the functionality does not meet the requirements, there are functional errors, or the functionality does not match the general taste.
2. Six elements of a defect/bug#
1) Title:#
Concisely describe the bug, where the bug occurred, and provide a summary of the problem. Highlight the role of keywords, ensure there are no syntax errors, and make it easy to search using keywords. It should be easy to assign to the next person.
2) Steps to reproduce:#
Provide a complete and concise description of each step to reproduce the bug. It is not necessary to include every small step, but ensure that any relevant member can understand the problem. Ensure that the problem can be reproduced based on the description. If there are prerequisites, provide a concise introduction and relevant test data.
3) Actual result:#
Describe the actual result observed. Do not use a screenshot to replace the description.
4) Expected result:#
Describe the correct and standard result associated with the actual result.
5) Environment information:#
System and browser (optional for the defect system submission). If there is additional environment information to be supplemented, please provide it below the expected result.
6) Attachments:#
For images, mark the problem area with a clear brush if necessary, and provide a brief explanation. For videos, complete the process of reproducing the problem as quickly as possible. For logs, provide complete relevant logs without including a large amount of unrelated logs.
3. Points to note when submitting a bug#
In addition to the six elements of a bug, pay attention to the following points:
Accurately fill in "Module," "Project," "Affected Version," "Type/Severity," and "System/Browser."
"Current Assignee" refers to the developer in charge (if unsure, please ask the testing person for assistance).
The bug title does not need to include the subsystem name, as it has already been selected in the product module.
Assign the bug to the contact person for initial analysis and "CC" the superior.
Edit the bug's priority. It is hoped that 20% of defects are of priority 1 or 2. Bugs have different levels of urgency, so prioritize solving high-value problems.
4. Defect investigation (10 Whys)#
(What) What is the problem? What is the impact?
(Why) Why does this problem occur? In what scenarios does it occur?
(Where) At which stage was the problem discovered?
(Which) At which stage was the defect introduced?
(Why) Why was the problem introduced at this stage?
(How) How can we avoid introducing this problem?
(Where) At which stage should this problem be discovered?
(Why) Why was this problem not discovered at this stage?
(How) How can we discover this problem at this stage?
(How) How can we improve the process based on risk testing and extract estimated product risks?