How to enter a bug that everyone thinks is good, especially the developer that thinks it is good. A basic principle of writing a bug report is to objectively state all relevant facts.
The first point reports the version in which the problem was found
Developers need to be instructed in which version the problem occurred in order to obtain an identical version to reproduce the problem, and the identification of the version helps to analyze and summarize the concentration of the problem.
It should be noted that some bugs appeared in version 1.1. The tester entered the bugID as 101, the developer modified it and the verification was closed, but it appeared again in 1.4. At this time, the tester changed the status of 101 to reopen, which It is wrong, because this appeared in the new version, even if it is the same phenomenon, or even the same reason, but it should not be reopened, but a new one. Because this represents a quality regression problem, this defect does appear again, and changing to reopen may cause a defect to be missed in the quality statistics. Testers need to re-register, test, verify, report, and developers need to re-modify and compile.
The second point reports the environment in which the problem occurs
The environment in which the problem occurs includes the operating system environment, the software configuration environment, and sometimes system resource usage, because some errors appear when resources are insufficient.
Because the development environment, the test environment and the actual use environment of the customer are quite different, it should be considered whether the problem is affected by the software and hardware environment or configuration. For example, some third-party plug-ins that need to be registered cause the report to open properly.
Step 3 to report the problem to reproduce
It should describe the minimum set of steps that must be performed to reproduce the problem.
Some testers often write down the steps to reproduce and report bugs as soon as they find problems. In fact, such errors may only occur when a combination of some of the key steps occurs, so the correct way is Try a few more times and try to reduce the steps to the steps necessary to reproduce the error.
The fourth point describes the expected behavior
Let the developer know what is right, especially from the client's point of view to describe how the program should behave. Clearly stating the expected behavior of the program can better express the requirements. Don't be ambiguous, let the developer know exactly what they want.
The fifth point describes the observed misbehavior
Describe the phenomenon of the problem, objectively state and reflect the facts, do not exaggerate and do not sarcasm.
Point 6: Self-inspection before submitting
There should be no typos in the content of the article, and if the description is ambiguous and unclear, do not enter several bugs into one ID report at the same time, and read it by yourself after recording a bug.
In addition to the version of the bug, the environment in which it appeared, the steps to reproduce, the expected behavior, and the wrong behavior mentioned above, it is also possible to register the defect level of the bug, the module corresponding to the bug and its location, the type of the defect, and the date of discovery. , user reporting date, etc. Necessary exception information files, log files, input data and output data, front-end screenshots, etc. can be added to the bug report as attachments, which is convenient for developers to locate.