Pesticide paradox is a contradictory concept of defect clustering.In Defect Clustering we have seen that a particular module having large number of defects are tested again and again. So in this way the defect is removed from that particular module but there is a possibility of defects in other modules. This concept is called pesticide paradox where same set of test are performed again and again over a module and a time comes when defect remaining in that module is zero but the other modules remains untouched.
The name pesticide paradox is derived from the real time scenario where same kind of pesticide makes the insects immune to it similarly execution of same cases again and again does not finds new bug in the system.
So in order to find new bugs we need to change the test cases. Old regression scripts/suites needs to be updated.The test cases need to be revised, and new and different tests need to be written to exercise different parts of the software or system to potentially find more defects.
Now we have two choices.
1.To write whole new set of test cases to exercise different parts of the software.
2.To prepare new test cases & add them to the existing test cases.
In the first case,we will be finding more potential defects in an area where we did not focused earlier or the area at which developer was not extra cautious as the tester was not raising the defects from these areas. But by neglecting earlier identified defect cluster, we are certainly taking a risk of giving less importance to the area which used be very critical in order to find the more defects in earlier iterations of testing.
In the second case,we can find the new potential defects in the new area as well as we can focus on the earlier identified defect cluster. But on the other hand the number of test case will become so large that it will increase the testing time & in turn increase the cost of testing. Hence too many useless tests may be an overhead.
The name pesticide paradox is derived from the real time scenario where same kind of pesticide makes the insects immune to it similarly execution of same cases again and again does not finds new bug in the system.
So in order to find new bugs we need to change the test cases. Old regression scripts/suites needs to be updated.The test cases need to be revised, and new and different tests need to be written to exercise different parts of the software or system to potentially find more defects.
Now we have two choices.
1.To write whole new set of test cases to exercise different parts of the software.
2.To prepare new test cases & add them to the existing test cases.
In the first case,we will be finding more potential defects in an area where we did not focused earlier or the area at which developer was not extra cautious as the tester was not raising the defects from these areas. But by neglecting earlier identified defect cluster, we are certainly taking a risk of giving less importance to the area which used be very critical in order to find the more defects in earlier iterations of testing.
In the second case,we can find the new potential defects in the new area as well as we can focus on the earlier identified defect cluster. But on the other hand the number of test case will become so large that it will increase the testing time & in turn increase the cost of testing. Hence too many useless tests may be an overhead.
No comments:
Post a Comment