DEFECT CLUSTERING AND PESTICIDE PARADOX:

 

Defect Clustering and Pesticide paradox are among the two important principles of testing.

Definitions:

Defect Clustering:

When a small number of modules contains most of the bugs detected or show the most operational failures.

Pesticide Paradox:

If the same tests are repeated over and over again, eventually the same test cases will no longer find new bugs. This is what pesticide paradox is actually referring to.

Overview of Defect Clustering:

Defect clustering actually means that the distribution of defects are not across the application uniformly, but rather centralized in limited sections of the application. It is particularly true for large systems where the complexity, size, change and developer mistakes can impact the quality of the system and affect particular modules.

It is based on the Pareto principle, also known as the 80-20 rule, where it stated that approximately 80% of the problems are caused by 20% of modules.

While testing, most of the testers have observed this phenomenon which basically happens because an area of the code is complex and tricky. Test designers often use this information when making the risk assessments for planning the tests, and will focus on these known areas that may also be called as Hotspots.

 

 

Advantages:

•  Tester can focus the same area in order to find the more number of defects.
•  Helps in reducing the time and cost of finding defects.

Overview of Pesticide Paradox:

After certain number of iterations of testing, as the testing improves, the defect numbers starts dropping, most of the bugs will be fixed and the ‘Hot Spot’ area will be cleaned up. Developers will be extra careful in those places where testers found more defects and might not look in to other areas.

Hence, by executing the same test cases will no longer help to find more defects. The test cases needs to be revised and new and different tests needs to be written to exercise different areas of the software or system to potentially find more defects.

 

Methods to prevent pesticide paradox:

•  To write whole new set of test cases to exercise different parts of the software.
•  To prepare new test cases and add them to the existing test cases.

By following the above two methods of prevention, it is possible to find more potential defects in an area where testing has not been focused earlier or the area at which developer was not extra cautious as the tester was not raising the defects from these areas.

Also, from the second method of prevention, new potential defects from the new area can be found out as well as focus on the earlier identified defect cluster is also there which used to be very critical earlier.

But when the second method of prevention is followed, number of test cases will be too large that will increase the testing time and in turn will increase the cost of testing.

To overcome this, the testers should identify and remove the test cases that are not that much important and should prioritize the test cases and proceed accordingly.

In this way, testers can keep the check on number of useless test cases without compromising with the quality as all the test cases covering important areas of the software will be retained.

Conclusion:

In the initial iterations of testing, identifying the defect cluster is useful but it is not a good practice to assume that all the defects are hidden in that defect cluster only even in the later iterations too.

Even though the created test cases have a very high coverage percentage and high rate of finding defects we still need to keep reviewing test cases regularly.