For a tester, the life cycle of bugs is generally divided into: discover bugs → submit bugs → verify bugs → close bugs
It can be divided into three stages:
Stage 1: Finding bugs
Scenes:
" Isn't testing just about finding bugs? What technical content is there? "
think:
When a bug is found, what else can we do besides reporting the problem as soon as possible?
answer:
Testers find bugs, take some time to savor them
1) What are the necessary conditions for this bug to reproduce?
2) Apart from this path where the bug was found, are there any more paths that would cause the same problem?
3) Does the bug have side effects that might affect other data or other applications?
4) Do other functional modules have similar problems?
5) Is the bug's recurrence path on the user-accessible path?
6) Is the path to reproduce the bug in the test case? Is there any reference?
Through the above analysis, we may obtain the following additional benefits:
1) By locating bugs, confirm the inevitable path and possible causes, and help developers quickly locate and solve problems
2) Discover more hidden bugs through the analysis of the bug's path, scope of influence, etc.
"Exploratory Test" - Evil Neighbor Test: Hard-hit areas tend to have more bugs
3) By analyzing the operation path, supplement the test cases, and expand the scope and ideas of the test cases
Stage 2: Submit a bug
Scenes:
The tester submits a bug without a detailed description, and the development cannot be started, and the cause of the bug cannot be found, so he decides not to modify it.
Thinking: How can I submit a valid bug?
answer:
1. Make sure the bug is valid.
1) Do not cause "bugs" due to environmental problems or operational errors
2) Don't submit some duplicate bugs
2. Write a good bug description.
1) The bug description is accurate, without ambiguity, and the test steps are detailed and concise.
2) Ensure that the content of each field is consistent with the actual phenomenon. For example: version, recurrence rate, etc.
3) For problems with low recurrence rate, provide some reference information as much as possible: screenshots, videos, logs, possible steps, possible reasons, etc. ( If you can locate the cause of the problem through various means, the developer will also you are impressed )
4) For special test scenarios, attach relevant data, such as 1024kb pictures, etc.
Stage 3: Verifying bugs
Scenes:
For novice testers, for bug verification, it is often to verify and reproduce according to the steps, and if there is no problem, close it
Thinking: How to do bug regression verification?
answer:
1. Confirm the premise and operation steps for the reproduction of the bug.
2. Confirm the cause of the bug and how to fix it.
1) Clarify the cause of bugs, bypass analogies, and analyze possible problems in other modules
2) Accumulate test experience and expand test ideas through the causes of bugs
3) Through the bug modification method, can the analysis and modification fix the problem? Does it cause other problems?
4) Accumulate bug experience, quickly locate the problem and provide solutions when the subsequent related problems are discovered
3. Confirm the regression scope and use case of the bug.
On the basis of understanding the cause of the bug and the repair method, confirm the regression scope according to the business association and functional module association to ensure that the bug repair is comprehensive and does not cause new bugs
Stage 4: Closing the bug
If the tester confirms that the bug has been resolved after retesting, set the bug's status to "Closed"