Paradox is a state where a person cannot actually come to a conclusion; it is an irresolute state wherein the person will not be confident enough to decide the meaning. It is a statement which appears to be contradicting itself.
Examples:
- Nobody goes to that restaurant, it’s too crowded.
- If you didn’t get this message, call me.
Pesticide Paradox: The pesticide paradox states that applying pesticides to kill pests in a farm may actually cause an abundance of these pests if the predator-prey dynamics in the eco system is disrupted. This situation arises when the predator is as equally affected by the pesticide as is the prey (pest).
How can the above concept be used in software testing?
Application of the Pesticide paradox comes to picture while maintaining Test suites. This concept is extremely helpful in long term projects.
How & when will a tester confidently be able to state “my Test suite is capable enough to catch all defects in the application”? It is understood that a Test suite that is created at the beginning of a project will not be helpful after several releases. Every release brings with it a set of new features and/or changes to existing features. Very quickly, the old test suite becomes outdated. It is subject to obsoleteness.
So here is the Software Testing Pesticide Paradox: It states that if we executed the same Test cases over and over again, over time we would probably find that the amount of new defects identified would decrease. Running the same tests repeatedly would not bring up any new defect because all defects found using the initial Test cases would eventually all be fixed.
In order to avoid this, the Test suite needs to be updated in parallel as new features arrive.
How do we update our test suite effectively?
- Firstly identify changes to existing feature and update the test suite.
- If some features are removed from the application, it is better to remove Test cases related to it or keep them separately after archiving them.
- There may be redundant Test cases. If so, then it is time to delete those from the Test suite – this makes your test suite more agile.
- Identify how new feature and existing features are related. If you feel you need to write new Test case(s) then go ahead, otherwise modify existing ones.
- After a release, identify all ad hoc defects identified during the release and add Test cases for or modify existing ones to cover this defect.
Automated Test suite:
- Delete or modify test script(s) if the Test case related to it is modified.
- Delete or archive unwanted test scripts.
- Try to add more scripts related to new features so that it will be helpful for the current release (Only if that feature is not going to change – Need to confirm this with developers).
- Automate more scripts related to ad hoc scenarios/new Test cases so that Automation scripts can find more bugs.
- Try to improve overall Automation framework by adding more recovery scenarios – this makes the test suite more robust.
- Identify scripts that consume more execution time and try to improve the performance of execution by coming up with new logic.
These are some simple steps that we can follow to be in a position to say “Yes, our test suite is able to find bugs!”