There are several key indicators in the QA report of our project, such as the thousand-line code defect rate, the version test package replacement rate, the fatal/serious bug rate, the remaining bug rate, and the bug recovery rate. The latest QA report shows that the replacement rate of the Android client version of a product has reached more than 50%, which means that there is a package replacement in every two testing.
If there is a package change in the test version, there are usually obvious quality problems. To solve this problem, our idea is:
First, there are roughly two types of reasons why testers collect history to change packages. One is that the main function of the test is unavailable. The reasons include code leakage, code coverage, problems with the main code logic, etc., and the other is the newly added The functionality affected the original core functionality, preventing the test from continuing. Both of these two types of problems can be discovered in time through self-tests that test the main functions and core functions.
Second, testers give a list of main functions and core checkpoints for testing, and require developers to conduct self-tests before testing versions, and focus on the problems of historical package replacement to avoid repeated pit mining. It should be noted here that in order to avoid the formalization of this process, it is necessary to communicate with the developer and the development leader. If there is an item that fails in the self-test checkpoint, the tester can directly call back the test. Developers need to pass the self-test again and then initiate the testing process.
Third, testers should update the checkpoint list in time and consider the checkpoint automation scheme to further improve the test efficiency.
ps:
After the new version implements the self-test process, the replacement rate of the Android terminal has dropped to about 10%, and the effect is remarkable.