Common pitfalls for automation frameworks

While designing “Automation frameworks” following are some of pitfalls to avoid to keep “Low maintenance” of scripts:

  • Avoid test scripts with local test data

Generally seen in module driven automation frameworks, where test data (Data with which we are supposed           to perform testing) is embedded into automation scripts. Thus, whenever we are supposed to test with a                     different / multiple set of test data, script needs maintenance.

  • Test script dependent for specific O.S. / Browser / DB / Device

Having scripts limited to run for specific browser / OS / DB / Device needs to be designed and flexible to                   detect test environment and complete tests for supported environments.

  • Test scripts designed to run sequentially or specific order

Scripts designed to run sequentially in specific order invites pain points to re-run scripts for end to end                     coverage provided there is failure in between due to network / run-time conditions etc.

  • Framework designs not enhancing time to test

With growing numbers of scenarios, environments it becomes cumbersome to complete regression in time                and organizations need to depend on run results to complete.  Framework needs to be designed for parallel              execution across systems thereby load balancing tests and improving time to test.

  • Designed for flexibility

With frequent changes in features / test needs to extend all capabilities of framework without the need to redesign framework.  Frameworks needs to support such modularity thereby maintaining testing standards.

  • Designed for Run logs / custom reports 

Frameworks needs to be designed to capture run logs while tests are executed and prepare custom reports to provide address statistical details on coverage and help decide quality trends.