Test Automation Patterns
What is a pattern?
A pattern is a general reusable solution to a commonly occurring problem within a given context. They are commonly used in software development.
A test automation pattern is a way of solving an issue or problems in test automation that has worked in practice for many people. In other words, a pattern is expert knowledge proven by repeated experience.
Patterns do not exist in a void: each is a solution to an issue that occurs under some particular conditions. Also patterns are often associated with other patterns, either because they can only be implemented using other patterns or because they can only be applied after other patterns have been put into practice. As an example think about the pattern “car”: can you really believe that we could use this “pattern” so successfully if we hadn’t also implemented the patterns “paved road” and “gas station”?
The relationship to other patterns forms the “grammar” of a pattern language. Just as in English you cannot write the parts of a sentence in a gratuitous sequence, but you must follow rules, so also with test automation patterns you have to follow their natural hierarchy.
In this wiki, we show PATTERNS in CAPS.
What a pattern is not
A pattern is not
- a finished solution that you can just "plug in" directly to your situation
- prescriptive (you must do this)
- a step-by-step procedure (do this first, then that)
Patterns are ideas that you can adapt and implement in your own context and which will hopefully help solve some of your issues
Typical test automation patterns:
The following are some solutions that are described in the patterns in this wiki.
- a description of how testware should be organised, designed and developed, in order to solve test automation problems (ABSTRACTION LEVELS, TESTWARE ARCHITECTURE, KEYWORD-DRIVEN TESTING)
- a rule about how to perform a particular step in a test automation process, for example to improve efficiency
(AUTOMATE WHAT'S NEEDED, GOOD PROGRAMMING PRACTICES, MAINTAIN THE TESTWARE) - a suggestion about how to resolve a management issue (SET CLEAR GOALS, DO A PILOT, DEDICATED RESOURCES)
- ways of dealing with test execution problems (FAIL GRACEFULLY, STEEL THREAD, KILL THE ZOMBIES)
- a description of a behaviour that, if not contained, may compromize the entire automation project (Failure Patterns). These are not actually patterns as we use the term, but "anti-patterns", i.e. things that you should NOT do. They are really issues, but "failure patterns" is a good description of them and is what Michael Stahl called them.
Classification of patterns:
Patterns have been divided into categories depending on their scope:
| Process Patterns |
| Management Patterns |
| Design Patterns |
| Execution Patterns |
Within each category the patterns are listed alphabetically.
The Test Automation Patterns Mind Map shows an overview of the Test Automation Patterns, and for each of the four categories, there is a mind map showing the Patterns with the next level of patterns (with a "+" symbol to indicate further "called" patterns. These mind maps are static within this wiki (you can't click on them, they are not automatically updated).
Main Page