False positives and false negatives in testing are equally worthy of repeated corrections

During the production process, if the test case fails to execute, the problem may not necessarily be caused by external factors.Even leading to capital loss, these omissions are caused by underreporting.
Then, whether it is a false positive or a false negative, it will lead to the rework of the product team, and it is also the biggest waste.

Rework of false positives

In the testing process, we often encounter that the reason for the failure of the test case is not caused by the BUG of the system under test, but caused by some test environment, test data, external dependencies, etc. Although these cannot be defined as BUG,But it also caused a rework of the test work and thus also needed to address false positives.

False positives are waste of internal artifact processes.In the quality assurance process, from the card opening in the demand stage, we have invested test engineers to participate. For the interfaces that the R&D engineers need to change in the process of completing the requirements, we have prepared a case for automatic interface testing in advance, and after completing the card inspectionThe automated test of the newly added interface is triggered by the pipeline to complete the corresponding quality assurance activities. These investments are all to improve the smoothness of the delivery process.If the automated test fails when it is triggered, we prefer that the failure state is caused by the bug of the system under test, but in reality, it is often due to the dependence of some external systems, the pollution of local test data and other peripherals.Caused by the reason, not the BUG of the tested system, this is the BUG false positive, which we refer to as false positive.
Although the test failure is not caused by the bug of the system under test, the false positive also needs attention because it leads to the rework of the test work.For false positives, you can enter the iterative process stage by adding a technical requirement card, which can not only leave marks in the team, but also prevent the problem of false positives from recurring.After adding the card, some R&D engineers decide whether to solve it in this iteration or in a future iteration.

Unreported losses

The principles of software testing presented in the first edition of the software reviewer's tutorial are clear