Test Automation Pitfalls (3)

Continuing from the previous posts, we look at another factor contributing to less than effective test automation.

3. Stability of the system being tested and the ability of the automation suite to adapt to changes to the system

There are two parts to this – one, the system or application that is being tested needs to be in a relatively stable state before you embark on an extensive automation exercise. If you try to build your automation suite when the system on which these automation tests are based upon keeps changing frequently, you are guaranteed to encounter – false test results being reported by automation runs and ever increasing maintenance activities on your suite. We must however, realize that despite calling for “relative stability”, there will be some changes and any test automation exercise must accept and be open to some amount of change. Having a stable product can help minimize these changes.

This is where we look at part two, which is the ability of the test automation suite to adapt to changes to the product it is testing. When test automation is not based on a sound framework that can minimize the impact of changes to the system under test, extensive maintenance activities need to be performed. This can have the added effect of affecting stakeholder perception of both the reliability and usefulness of your automation suite.

From a process stand-point, when major changes are planned to be made to the system under test, these must be reviewed to evaluate their impact on existing test suites. Any resulting test automation activity must be planned and communicated appropriately.