Difference between revisions of "UNATTENDED TEST EXECUTION"

From Test Automation Patterns
Jump to navigation Jump to search
(Created page with "<div id="content_view" class="wiki" style="display: block"> <span style="font-size: 14px">.......................................................................................")
 
 
(3 intermediate revisions by 2 users not shown)
Line 2: Line 2:
  
 
<span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Execution Patterns]] / Back to [[Test Automation Patterns]]</span><br />  
 
<span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Execution Patterns]] / Back to [[Test Automation Patterns]]</span><br />  
=<span style="font-size: 16px">Pattern summary</span>=
+
=<span style="font-size: 16px">'''Pattern summary'''</span>=
<span style="font-size: 16px">Automated tests should start automatically and run unattended.</span><br /> <br />  
+
<span style="font-size: 16px">Automated tests should start automatically and run unattended.</span><br />  
=<span style="font-size: 16px">Category</span>=
+
=<span style="font-size: 16px">'''Category'''</span>=
<span style="font-size: 16px">Execution</span><br /> <br />  
+
<span style="font-size: 16px">Execution</span><br />  
=<span style="font-size: 16px">Context</span>=
+
=<span style="font-size: 16px">'''Context'''</span>=
<span style="font-size: 16px">This pattern is appropriate when your automated tests will be around for a long time.</span><br /> <span style="font-size: 16px">This pattern is not appropriate for one-off or disposable scripts.</span><br /> <br />  
+
<span style="font-size: 16px">This pattern is appropriate when your automated tests will be around for a long time.</span><br /> <span style="font-size: 16px">This pattern is not appropriate for one-off or disposable scripts.</span><br />  
=<span style="font-size: 16px">Description</span>=
+
=<span style="font-size: 16px">'''Description'''</span>=
<span style="font-size: 16px">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).</span><br /> <br />  
+
<span style="font-size: 16px">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).</span><br />  
=<span style="font-size: 16px">Implementation</span>=
+
=<span style="font-size: 16px">'''Implementation'''</span>=
<span style="font-size: 16px">In order to support unattended test execution you must set up a supporting infrastructure. Some suggestions:</span><br />
+
<span style="font-size: 16px">In order to support unattended test execution you must set up a supporting infrastructure. Some suggestions:</span>  
 
 
 
* <span style="font-size: 16px">[[DEDICATED RESOURCES]]: run your tests on dedicated machines to avoid disruptions by other users.</span>
 
* <span style="font-size: 16px">[[DEDICATED RESOURCES]]: run your tests on dedicated machines to avoid disruptions by other users.</span>
 
* <span style="font-size: 16px">[[GET ON THE CLOUD]]: in the cloud you can easily (and cheaply) simulate as many environments as you need.</span>
 
* <span style="font-size: 16px">[[GET ON THE CLOUD]]: in the cloud you can easily (and cheaply) simulate as many environments as you need.</span>
Line 21: Line 20:
 
* <span style="font-size: 16px">Produce [[READABLE REPORTS]] that enable testers to see at a glance if and where there has been a failure.</span>
 
* <span style="font-size: 16px">Produce [[READABLE REPORTS]] that enable testers to see at a glance if and where there has been a failure.</span>
 
* <span style="font-size: 16px">[[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).</span>
 
* <span style="font-size: 16px">[[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).</span>
<br />
+
=<span style="font-size: 16px">'''Potential problems'''</span>=
=<span style="font-size: 16px">Potential problems</span>=
+
<span style="font-size: 16px">People looking for whether the tests passed (green) or failed (red) may be colour-blind! (Yes it has happened.)</span><br /> <span style="font-size: 16px">The tests need to be able to recover from catastrophic failures, and this does take effort to build in.</span>  
<span style="font-size: 16px">People looking for whether the tests passed (green) or failed (red) may be colour-blind! (Yes it has happened.)</span><br /> <span style="font-size: 16px">The tests need to be able to recover from catastrophic failures, and this does take effort to build in.</span><br /> <br />  
+
=<span style="font-size: 16px">'''Issues addressed by this pattern'''</span>=
=<span style="font-size: 16px">Issues addressed by this pattern</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">''[[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 add your name and a brief story of how you used this pattern: your context, what you did, and how well it worked - or how it didn't work!</span><br /> <br /> <span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Execution Patterns]] / Back to [[Test Automation Patterns]]</span></div>
+
 
 +
<span style="font-size: 16px">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.</span><br /> <br />  
 +
 
 +
 
 +
<span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Execution Patterns]] / Back to [[Test Automation Patterns]]</span></div>

Latest revision as of 16:05, 21 August 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 Feedback to submit your experience or comment.


.................................................................................................................Main Page / Back to Execution Patterns / Back to Test Automation Patterns