Difference between revisions of "UNATTENDED TEST EXECUTION"
m (empty lines removed) |
|||
| Line 25: | Line 25: | ||
<span style="font-size: 16px">''[[INEFFICIENT EXECUTION]]''</span><br /> ''<span style="font-size: 16px">[[INFLEXIBLE AUTOMATION]]</span>''<br /> <span style="font-size: 16px">''[[MANUAL INTERVENTIONS]]''</span><br /> <span style="font-size: 16px">''[[NO PREVIOUS TEST AUTOMATION]]''</span> | <span style="font-size: 16px">''[[INEFFICIENT EXECUTION]]''</span><br /> ''<span style="font-size: 16px">[[INFLEXIBLE AUTOMATION]]</span>''<br /> <span style="font-size: 16px">''[[MANUAL INTERVENTIONS]]''</span><br /> <span style="font-size: 16px">''[[NO PREVIOUS TEST AUTOMATION]]''</span> | ||
=<span style="font-size: 16px">'''Experiences'''</span>= | =<span style="font-size: 16px">'''Experiences'''</span>= | ||
| − | <span style="font-size: 16px">If you have used this pattern, please | + | |
| + | <span style="font-size: 16px">If you have used this pattern and would like to contribute your experience to the wiki, please go to [[Experiences]] to submit your experience or comment.</span><br /> <br /> | ||
| + | |||
| + | |||
| + | <span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Execution Patterns]] / Back to [[Test Automation Patterns]]</span></div> | ||
Revision as of 09:31, 5 July 2018
.................................................................................................................Main Page / Back to Execution Patterns / Back to Test Automation Patterns
Pattern summary
Automated tests should start automatically and run unattended.
Category
Execution
Context
This pattern is appropriate when your automated tests will be around for a long time.
This pattern is not appropriate for one-off or disposable scripts.
Description
Automated tests bring the most Return on Investment when they are scheduled to start automatically and run unattended. Results should be presented so that testers only have to check for failures (for instance colour coded).
Implementation
In order to support unattended test execution you must set up a supporting infrastructure. Some suggestions:
- DEDICATED RESOURCES: run your tests on dedicated machines to avoid disruptions by other users.
- GET ON THE CLOUD: in the cloud you can easily (and cheaply) simulate as many environments as you need.
- Set up the “Planned Task” feature to start your tests automatically at a given date and time.
- Design INDEPENDENT TEST CASES so that tests don’t disrupt each other.
- FAIL GRACEFULLY so that failed tests don’t compromise a whole test suite.
- VISUALIZE EXECUTION so that you can peek in at any time to find out how far the execution has got.
- Produce READABLE REPORTS that enable testers to see at a glance if and where there has been a failure.
- THINK OUT-OF-THE-BOX to find tasks that can be automated around the test execution, for example in pre-processing (set-up) or post-processing (analytical tools for test results).
Potential problems
People looking for whether the tests passed (green) or failed (red) may be colour-blind! (Yes it has happened.)
The tests need to be able to recover from catastrophic failures, and this does take effort to build in.
Issues addressed by this pattern
INEFFICIENT EXECUTION
INFLEXIBLE AUTOMATION
MANUAL INTERVENTIONS
NO PREVIOUS TEST AUTOMATION
Experiences
If you have used this pattern and would like to contribute your experience to the wiki, please go to Experiences to submit your experience or comment.