Design your testware so that it does not have to be updated for every little change in the Software Under Test (SUT).
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.
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)
- 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!
- 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.
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
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.