Defects in title
The usual model is what went wrong under what circumstances
First
What problem must be described at the same time as clearly stating the context in which the problem occurred, i.e., the context in which the problem occurred
Second
Headings should describe the nature of the problem as much as possible, rather than merely scratching the surface of the problem
For example: “commodity amount input box, you can input English letters and other characters”, this description only describes the surface phenomenon of the problem; If you use “commodity amount input box, no verification of input content”, you can see the nature of the defect through the title, which can help developers quickly grasp the nature of the problem
Last
The defect title should not be too long. A more detailed description of the defect should be placed in the Defect Overview
Defects affect
Priority: The development determines the priority of fixing the defect based on this
Severity: Measures the severity of a defect and determines whether to release the product until the defect has been fixed
Environment configuration
It mainly provides necessary environment information for reproducing defects, such as the type and version of operating system, software version under test, type and version of browser, configuration information of software under test, configuration parameters of cluster, and version information of middleware
The main thing to note is that the content of the environment configuration is usually described on demand, meaning that only environment-sensitive information that reproduces defects is usually described
For example, “missing an item in the menu bar” only happens in Chrome, and no other browser has the same problem. So Chrome is environment-sensitive information that must be described, and it doesn’t matter what operating system Chrome is running on
precondition
A precondition is the state that the system should be in before the test steps begin, in order to reduce the description of defect recurrence steps. Proper use of preconditions can eliminate unnecessary interference in describing defect recurrence steps
Such as:
- If a service operation requires user login, you do not need to describe the details of the login operation in the defect reappearance step. You can add “Prerequisite: User login”.
- Before logging in to the system under test, you need to prepare test users in advance. You can add “Prerequisite: The user has been registered” instead of adding “Generate new users” in the defect re-step.
Repeat steps
From the user’s point of view, each step should be actionable and coherent, so a list of steps is often used.
- Ensure reproducibility of defects
- Find the shortest return path and filter out unnecessary steps
Expected results and actual results
When describing desired outcomes: Need to state what should happen, not what should not happen
When describing actual results: need to say what happened, not what didn’t happen
Priority and severity
Severity, which is an attribute of the defect itself, is usually fixed
Priority is the engineering attribute of defects, which will change with the project progress, the cost of solving defects and other factors
The relationship between priority and severity
- The more serious the defect, the higher the priority
- The larger the defect scope, the higher the priority
- Some defects do not affect the use of users, but will hinder the normal execution of the test, such as low severity, high priority
- Some defects, although more serious, may be of lower priority due to the cost and technical difficulty of fixing them
workarounds
Providing a way to temporarily bypass a current defect without affecting product functionality
The availability of workarounds and the difficulty of implementation are the important basis for determining the priority and severity of defects.
If there is no workaround for a serious defect, the priority must be highest regardless of the cost of fixing the defect, not necessarily highest if there is a simpler workaround for the defect
Root Cause Analysis
Generally speaking, RCA is best if it can locate the root cause of the problem at the same time as discovering the defect