Difference between revisions of "OBSCURE TESTS"
Jump to navigation
Jump to search
m (Topic titles in capital letters) |
m (empty lines removed) |
||
| Line 1: | Line 1: | ||
| − | <div id="content_view" class="wiki" style="display: block"><span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Design Issues]] / Back to [[Test Automation Issues]]</span | + | <div id="content_view" class="wiki" style="display: block"><span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Design Issues]] / Back to [[Test Automation Issues]]</span> |
=<span style="font-family: Arial; font-size: 16px">'''Issue summary'''</span>= | =<span style="font-family: Arial; font-size: 16px">'''Issue summary'''</span>= | ||
| − | <span style="font-family: Arial; font-size: 16px">Automated tests are very complex and difficult to understand</span | + | <span style="font-family: Arial; font-size: 16px">Automated tests are very complex and difficult to understand</span> |
=<span style="font-size: 16px">'''Category'''</span>= | =<span style="font-size: 16px">'''Category'''</span>= | ||
<span style="font-size: 16px">Design</span> | <span style="font-size: 16px">Design</span> | ||
| Line 10: | Line 10: | ||
# <span style="font-size: 16px">Keywords have been implemented, but never maintained, so that nobody really knows what they do</span> | # <span style="font-size: 16px">Keywords have been implemented, but never maintained, so that nobody really knows what they do</span> | ||
# <span style="font-size: 16px">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</span> | # <span style="font-size: 16px">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</span> | ||
| − | |||
=<span style="font-family: Arial; font-size: 16px">'''Questions'''</span>= | =<span style="font-family: Arial; font-size: 16px">'''Questions'''</span>= | ||
| − | <span style="font-family: Arial; font-size: 16px">Who is doing the automation? A "lone hero"?</span><br /> <span style="font-family: Arial; font-size: 16px">Who is writing the automation test cases?</span><br /> <span style="font-family: Arial; font-size: 16px">Are there standards? If yes, are they used?</span | + | <span style="font-family: Arial; font-size: 16px">Who is doing the automation? A "lone hero"?</span><br /> <span style="font-family: Arial; font-size: 16px">Who is writing the automation test cases?</span><br /> <span style="font-family: Arial; font-size: 16px">Are there standards? If yes, are they used?</span> |
=<span style="font-family: Arial; font-size: 16px">'''Resolving Patterns'''</span>= | =<span style="font-family: Arial; font-size: 16px">'''Resolving Patterns'''</span>= | ||
<span style="font-family: Arial; font-size: 16px">Most recommended:</span><br /> | <span style="font-family: Arial; font-size: 16px">Most recommended:</span><br /> | ||
| − | |||
* <span style="font-size: 16px">[[ DOCUMENT THE TESTWARE]]: Use this pattern for issues similar to Examples 2. 3. or 4.</span> | * <span style="font-size: 16px">[[ DOCUMENT THE TESTWARE]]: Use this pattern for issues similar to Examples 2. 3. or 4.</span> | ||
* <span style="font-size: 16px">[[DOMAIN-DRIVEN TESTING]]: use this pattern to enable even non-technical testers to write and review test cases for automation</span> | * <span style="font-size: 16px">[[DOMAIN-DRIVEN TESTING]]: use this pattern to enable even non-technical testers to write and review test cases for automation</span> | ||
| Line 26: | Line 24: | ||
* <span style="font-family: Arial; font-size: 16px">[[TOOL INDEPENDENCE]]: use this pattern if you don't want everybody on the team to become a tool specialist</span> | * <span style="font-family: Arial; font-size: 16px">[[TOOL INDEPENDENCE]]: use this pattern if you don't want everybody on the team to become a tool specialist</span> | ||
<br /> <span style="font-size: 16px">Other useful patterns:</span><br /> | <br /> <span style="font-size: 16px">Other useful patterns:</span><br /> | ||
| − | |||
* <span style="font-size: 16px">[[DESIGN FOR REUSE]]: using this pattern forces the team to develop readable and maintainable testware</span> | * <span style="font-size: 16px">[[DESIGN FOR REUSE]]: using this pattern forces the team to develop readable and maintainable testware</span> | ||
* <span style="font-size: 16px">[[INDEPENDENT TEST CASES]]: apply this pattern to get rid of issues like Example 1.</span> | * <span style="font-size: 16px">[[INDEPENDENT TEST CASES]]: apply this pattern to get rid of issues like Example 1.</span> | ||
Revision as of 17:23, 7 May 2018
.................................................................................................................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 then 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