MAINTAINABLE TESTWARE

.................................................................................................................Main Page / Back to Design Patterns / Back to Test Automation Patterns

Pattern Summary

Design your testware so that it does not have to be updated for every little change in the Software Under Test (SUT).

Category

Design

Context

This pattern is applicable when your automated tests will be around for a long time, and/or when there are frequent changes to the SUT.
This pattern is not applicable for one-off or disposable scripts.

Description

Identify the costliest and/or most frequent maintenance changes, and design your automation to cope with those changes with the least effort. When adjustments really are necessary, then they should be relatively easy to implement. For example, if objects are frequently renamed, construct a translation table from the name you want to use in the tests, and put in whatever the name of the object is for the current release of the SUT. (OBJECT MAP)

Implementation

Some suggestions:

• There are many options to make and keep the testware maintainable, but to adopt a GOOD DEVELOPMENT PROCESS and GOOD PROGRAMMING PRACTICES is a very good bet: what works for software developers works for test automation just as well!
  • For example, if your scripts are mainly "stand-alone" without much re-use, and automators are frequently re-inventing similar or even duplicated scripts or automated functions, then GOOD PROGRAMMING PRACTICES are needed, particularly DESIGN FOR REUSE and OBJECT MAP.
• Implement DOMAIN-DRIVEN TESTING: test automation works best as cooperation between testers and automation engineers. The testers know the SUT, but are not necessarily adept in the test automation tools. The automation engineers know their tools and scripts, but may not know how best to test the SUT. If the testers can develop a domain-specific language for themselves to use to write the automated test cases, the automation engineers can implement the tool support for it. In this way they will each be doing exactly what they do best. The advantage for the automation engineers is that in this way the testers can do some of the maintenance of the tests themselves leaving the engineers more time to refine the automation regime, and to solve technical maintenance problems.
  • For example, if you have structured and reusable scripts, but there is a shortage of test automators to produce the automated tests (or they are short of time), this pattern gives the test-writing back to the testers, once the automators have constructed the infrastructure for the domain-based test construction. Other useful patterns are ABSTRACTION LEVELS and KEYWORD-DRIVEN TESTING.
• Don't forget to actually MAINTAIN THE TESTWARE: maintainability alone is not enough, it must actually be maintained.

Potential problems

Don't wait too long to build maintainable testware - this is best thought of right at the beginning of an automation effort (although it is also never too late to begin with improvements.)

Issues addressed by this pattern

BRITTLE SCRIPTS
DATA CREEP
HIGH ROI EXPECTATIONS
NO PREVIOUS TEST AUTOMATION
OBSCURE TESTS
SCRIPT CREEP
TOOL-DRIVEN AUTOMATION

Experiences

If you have used this pattern and would like to contribute your experience to the wiki, please go to Feedback to submit your experience or comment.

.................................................................................................................Main Page / Back to Design Patterns / Back to Test Automation Patterns