I have already mentioned what a bug is, and a bug is a software error. When the software specification exists and is correct, if the program is inconsistent with the specification, it will be regarded as a software error. For some functions not mentioned in the software specification, it will be based on the user's needs and expectations, and those that do not meet the user's reasonable expectations will be deemed Software errors;
for a tester, it can be narrowly considered that his job is to continuously find and submit bugs. This article will further introduce the content related to bugs:
describe a bug
In general, a reasonable bug description mainly includes the following parts:
- The version where the problem was found
For developers, only when they know the corresponding version when the tester raised the bug can they find the source of the problem according to the code corresponding to the corresponding version; - Environment where the problem occurs
For a web project, the environment represents the browser version, the operating system of the client, etc.; for an APP project, the environment includes the version of the operating system, the model of the APP installed, etc.; - Steps of the problem found
In order for developers to reproduce the bug faster and better, it is necessary for the tester to clearly reflect the detailed steps of the bug in the description of the bug; - Description of the expected result
The description of the expected result is a strong proof of why the bug is a bug, and it is also to let developers know what is correct and what effect needs to be obtained to make the modification successful; - Description of wrong behavior
A description of the actual situation is also a strong evidence to prove the bug;
It should be clear that the goal of creating a bug is to allow developers or other personnel to reproduce it and modify it. Therefore, the description of the bug should be as clear as possible, generally including but not limited to the above points, and generally according to the specific conditions of different companies. Additional elements are required;
Bug level
Regarding the grading of bugs, generally different companies have different requirements, here is only a brief introduction under common circumstances:
- Crash
directly leads to failure of development or testing work, system crash, crash, loss of database data, loss of main functional modules, etc.; - Serious
Some of the main functions of the system are lost, the functional design is seriously inconsistent with the requirements, there are problems with security and system stability, etc.; - General
The function is incomplete but does not affect normal use. The general level is roughly that there are problems but does not affect normal use; - Minor
functions can be used normally, but can be further optimized, the user experience is average, and optimization is better;
Bug life cycle
After submitting a bug, testers should continue to pay attention to the state transition of the bug until the end of its life cycle; the following is the state transition diagram of the bug:
new: newly discovered bug by the tester;
open: the bug is confirmed, and the developer will modify it;
rejected: it is not considered a bug, and the developer refuses to modify it;
fixed: the developer makes the modification;
delay: the modification is delayed for some reasons bug;
closed: After testing again by the tester, it is confirmed that the modification is successful, and the bug is closed;
reopen: After the test, the modification is not successful, and the bug is reopened;
Resolution of disputes with development
It is undeniable that every time a tester raises a bug, it means an increase in the workload of the developer. Therefore, it is inevitable to have a dispute with the development due to the bug. Here are some solutions:
- Confirm the bug you proposed, whether the description is not clear enough, whether an invalid bug is proposed;
- Check whether your bug rating is reasonable, refer to bug level and user experience;
- Guide developers from the perspective of users, whether users can tolerate the existence of such bugs;
- Improve your professional level as much as possible. When you propose a bug, you can give a reference for bug modification (just a suggestion, not to overwhelm the host);
- After the above process, if it is still not considered as a valid bug by the development, you can initiate a bug review (invite product representatives, development representatives, and test representatives to participate), communicate together, and solve problems such as how to modify the bug and how to avoid such problems;
over！