When one of the modules is found to have more defects, then the testers put some additional efforts to test that module.After a few iterations of testing, the quality of code gets improved and the defect count starts dropping as most of the defects are fixed by development team since the developers are also cautious while coding a particular module where the testers found more defects.
Hence, at one point, most of the defects are discovered and fixed so that no new defects are found in that module.
However, at times it may happen that while being extra cautious during coding on one particular module (here in our case the “Overdraft” module), the developer may neglect the other modules to code it properly or the changes made in that particular module might have a negative impact on the other functionalities like Account Summary, Funds Transfer and Standing Instructions.
When the testers use the same set of test cases to execute the module where most of the defects are found (Overdraft module) then, after fixing those defects by the developers those test cases are not much effective to find new defects. As the end to end flow of the Overdraft, the module is tested thoroughly and the developers also have written the code for that module cautiously. It is necessary to revise and update these test cases. It is also a good idea to add new test cases so that new and more defects can be found in different areas of software or application.
Preventive Methods of Pesticide Paradox
There are two options through which we can prevent Pesticide Paradox as shown below:
a) Write a new set of test cases which will focus on different area or modules (other than earlier defect prone module – Example: “Overdraft”) of the software.
b) Prepare new test cases and add to the existing test cases.
In the “method A”, testers can find more defects in the other modules in which they were not focused during the earlier testing or the developers were not extra cautious during coding.
In our above example, testers can find more defects in Account Summary, Funds Transfer or Standing Instructions modules using the new set of test cases.
But it may happen that the testers may neglect the earlier module (Example: “Overdraft”) where most of the defects were found in the earlier iteration and this could be a risk as this module (Overdraft) might have been injected with the new defects after coding of the other modules.
In the “method B”, new test cases are prepared so that new potential defects can be found in the rest of the modules.
Here in our example, newly created test cases will be able to help in identifying defects in the modules like Account Summary, Funds Transfer and Standing Instruction. However, testers cannot ignore the earlier defect prone modules (Example: “Overdraft”) as these new test cases are merged with the existing test cases.
The existing test cases were more focused on the “Overdraft” module and the new test cases were focused on the other modules. Hence all set of test cases are executed at least once even a code change happens on any module. This will ensure that proper regression gets executed and the defect can be identified due to this code change.
Using the second approach, the total test case count goes high significantly and results in more efforts and time required for execution. This will obviously impact on the project timelines and most importantly on the project budget as well.
Hence to overcome this problem, the redundant test cases can be reviewed and then removed. There are many test cases which become useless after adding new test cases and modifying the existing test cases.
It is necessary to check which test cases are failed in order to identify the defects in the last 5 iterations (let’s assume 5 iterations) and which test cases are not much important. It may also be the case that the single flow covered in a few test cases can be covered in another end to end test cases and those test cases having single flow can be removed.
This, in turn, will reduce the total test case count.
For Example, we have 50 test cases to cover one particular module and we have seen that out of these 50 test cases 20 test cases are failed to detect a new defect in the last few testing iterations (let’s assume 5 iterations). So these 20 test cases need to reviewed thoroughly and we need to check how important are these test cases and a decision can be made accordingly as whether to keep the 20 test cases or to remove them.
Before removing any test case, verify that the functionality flow covered in those test cases are covered in another test case. This process needs to be followed across all modules so that the total test case count significantly gets reduced. This will ensure that the total count of the test cases is reduced but there is still 100% requirement coverage.
It means that all the remaining test cases cover all the business requirements, hence there is no compromise on quality.