OBSCURE TESTS
Jump to navigation
Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
.................................................................................................................Main Page / Back to Design Issues / Back to Test Automation Issues
.................................................................................................................Main Page / Back to Design Issues / Back to Test Automation Issues
Issue summary
Automated tests are very complex and difficult to understand
Category
Design
Examples
- Manual testcases have been automated as is, that is they depict long scenarios that build on each other
- Automated scripts or data are not modular, are not documented and are stored with cryptical names, so that they practically cannot be reused
- Automation scripts are written in the proprietary language of the current tool and testers cannot read and much less run them
- Keywords have been implemented, but never maintained, so that nobody really knows what they do
- The automated test cases try to test too much all at the same time. This makes the tests not only slower, but also more fragile because they can fail in parts that actually have nothing to do with the original test
Questions
Who is doing the automation? A "lone hero"?
Who is writing the automation test cases?
Are there standards? If yes, are they used?
Resolving Patterns
Most recommended:
- DOCUMENT THE TESTWARE: Use this pattern for issues similar to Examples 2. 3. or 4.
- DOMAIN-DRIVEN TESTING: use this pattern to enable even non-technical testers to write and review test cases for automation
- GOOD DEVELOPMENT PROCESS,GOOD PROGRAMMING PRACTICES: these two patterns ensure that you get rid of issues similar to Example 2.
- MAINTAINABLE TESTWARE: Use this pattern to develop automation that can be used not only by the original developer
- ONE CLEAR PURPOSE: use this pattern is your issue is similar to Examples 1. or 5.
- REFACTOR THE TESTWARE: "bite the bullet" and take the time to re-organise the tests - it will save you time in the long run
- SET STANDARDS: this pattern helps you find a common language between all team members
- SINGLE PAGE SCRIPTS: use this pattern to modularize your scripts
- TOOL INDEPENDENCE: use this pattern if you don't want everybody on the team to become a tool specialist
Other useful patterns:
- DESIGN FOR REUSE: using this pattern forces the team to develop readable and maintainable testware
- INDEPENDENT TEST CASES: apply this pattern to get rid of issues like Example 1.
- KEEP IT SIMPLE: this pattern is always recommendable!
- KILL THE ZOMBIES: this pattern helps you clean up your scripts
- LEARN FROM MISTAKES: apply this pattern in order to transform your bad experiences in learning experiences
- MAINTAIN THE TESTWARE: this pattern is necessary as soon as you want to use your automation for more than a quick fix
- OBJECT MAP: This pattern helps you develop scripts that use readable names
.................................................................................................................Main Page / Back to Design Issues / Back to Test Automation Issues