1. What is a bug? A software bug usually refers to a bug or defect in a software program. In a broad sense, it also includes the details of the software that can be improved and proposed by the test engineer or user, or the implementation of functions that are different from the requirements document.
2. The life cycle of the bug. Defect status in the life cycle: New --> Assignment --> Resolved --> Pending inspection --> Close the found BUG -> Submit the BUG -> Assign the BUG -> R & D confirm the BUG -> R & D Go to fix the BUG -> regression test BUG -> pass the test -> close the BUG
1. Find bugs 1) Operate according to the test case, and find that the result is inconsistent with the expected result of the test case can be called a bug. 2) Cost issues, there is not enough time to write test cases, resulting in bugs. 3) Test cases cannot be exhausted, or bugs caused by misoperation.
2. Submitting a bug Before submitting a defect, first try to describe the attributes of the defect. Bug reproduction environment, bug type, bug level, bug priority and detailed reproduction steps, results and expectations, etc. Of course, before submitting a problem, we should first ensure that this defect has not been mentioned before, so as not to cause a duplicate defect list.
3. Assign bugs. This step is not necessary. It is related to the project mode. Some companies have independent testing departments and development departments, so the testers are not sure which developer is responsible for the modules they are testing. In this case, test The staff uniformly assign the problem to the project team leader or manager, and the project team leader (or manager) confirms the problem and assigns it to the corresponding developer again. Some testers are interspersed in different R&D teams, so the development modules responsible for different developers are very clear. At this time, the problem can be directly assigned to the corresponding developers. There is also a situation where the A developer should be responsible for this problem, but due to the transfer or resignation of the A developer, some problems are transferred to other personnel for handling. "Distribution" emphasizes the superior to the subordinate; the "transfer" emphasizes between the equal.
4. Confirming the defect. When the developer receives a defect, he first analyzes and reproduces it. If it is analyzed and found to be not a defect (maybe because the tester does not understand the requirements) or the problem cannot be reproduced, then You need to return this problem to the tester and indicate the reason. If it is confirmed as a defect, it needs to be dealt with. 5. Fix the bug and postpone the processing. After processing the problem, it is necessary to make a judgment, whether it is necessary to postpone the processing. Some requirements have been confirmed as the problem, because it may only appear in extreme cases, or the system architecture needs to be changed, or Its priority is very low, so there is no need to deal with this problem temporarily (or fix it in the next version). Fixed The problems that are delayed can be fixed temporarily ("fixed" is the name in QC.) Generally fixed problems can only be fixed after negotiation between the project manager and the test manager. Dealing with defects When the developer confirms that a problem needs to be dealt with, he will deal with it. (For example, redmine supports the processor to update the problem processing progress from time to time, such as 30% processed, 80% processed, etc. Of course, for problems that can be fixed in a short time, there is no need to update the processing progress from time to time.)
6. Regression Verification BUG Regression defects are very important work for testers. It has three entrances and two exits. Confirmation of non-defect problem: For a defect submitted, the developer treats it as non-problem or cannot be reproduced, and then directly forwards it to the tester for regression. The tester reconfirmed, if it is as the developer said, then close the problem. If the non-developer said that the problem was reproduced due to the vague description of the problem or other reasons, then the reason should be noted again and forwarded to the developer. Confirm and fix the problem: Reconfirm the problem fixed by the developer, and close the problem if it is confirmed. If the confirmation is not passed, open the question again and forward it to the developer. Confirm fixed issues: Plan to confirm fixed issues. As time goes by, some fixed issues may no longer exist in the version. Such issues should be closed in time. Some fixed problems still exist and become urgent. For such problems, they should be opened and handed over to developers for handling.
7. Close Defects Close the repaired defects, which is also the last state of a defect.
Third, use the tool Appropriate tools can effectively shorten the BUG handling process and improve work efficiency. I use the Eolinker interface management system, which is a domestic Saas tool. The test function and authority management distribution function are relatively complete, and it is also very helpful to our development team. Use address: www.eolinker.com 