How to efficiently and effectively report valuable defects?#
1. When should defects/issues/bugs be reported?#
- When the functionality does not meet the requirements or there are technical issues.
- 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, is incorrect, or does not align with popular preferences.
2. Six elements of a defect/bug report#
1) Title:#
Concisely describe the bug, where it occurred, and provide a summary of the problem. Highlight the keywords to facilitate easy searching and assignment to the next person. Ensure there are no grammar errors.
2) Steps to reproduce:#
Provide a complete and concise description of the steps 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 rely solely on screenshots.
4) Expected result:#
Describe the correct and standard result that should be expected. Relate it to the actual result.
5) Environment information:#
Include the system and browser information (optional for the defect reporting system). If there are additional environment details to be provided, include them below the expected result.
6) Attachments:#
For images, use clear annotations to indicate the problematic areas and provide a brief explanation if necessary. For videos, ensure they capture the entire process of reproducing the problem in the shortest possible time. For logs, include complete relevant logs without including unrelated logs.
3. Points to note when submitting a bug report#
In addition to the six elements of a bug report, the following points should also be considered:
- Accurately fill in the "module," "project," "affected version," "type/severity," and "system/browser" fields.
- Assign the bug to the responsible developer (seek assistance from the testing lead if unsure).
- 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 recommended that 20% of defects be assigned priority 1 or 2. Bugs have varying levels of urgency, so prioritize resolving high-value issues.
4. Defect investigation (10 Whys)#
- (What) What is the problem? What is its 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 that stage?
- (How) How can we discover this problem at that stage?
- (How) How can we improve the process of risk-based testing and extract estimates of product risks?