Difference between revisions of "Execution Patterns"

From Test Automation Patterns
Jump to navigation Jump to search
m (Contour lines added)
 
Line 1: Line 1:
 
<div id="content_view" class="wiki" style="display: block"><span style="font-family: Arial; font-size: 16px">Execution patterns show how to take care that test execution is easy and reliable. The table below gives a list of the Execution Patterns with a short description. The [[Execution Patterns Mind Map]] shows which other patterns are used by the execution patterns.</span><br /> <br />  
 
<div id="content_view" class="wiki" style="display: block"><span style="font-family: Arial; font-size: 16px">Execution patterns show how to take care that test execution is easy and reliable. The table below gives a list of the Execution Patterns with a short description. The [[Execution Patterns Mind Map]] shows which other patterns are used by the execution patterns.</span><br /> <br />  
{| class="wiki_table"
+
{| class="wiki_table" border="1" style="border-collapse:collapse"
 
! <span style="display: block; text-align: center"><span style="font-size: 16px">Pattern</span></span><br />
 
! <span style="display: block; text-align: center"><span style="font-size: 16px">Pattern</span></span><br />
 
! <span style="display: block; text-align: center"><span style="font-size: 16px">Description</span></span><br />
 
! <span style="display: block; text-align: center"><span style="font-size: 16px">Description</span></span><br />

Latest revision as of 13:06, 30 April 2018

Execution patterns show how to take care that test execution is easy and reliable. The table below gives a list of the Execution Patterns with a short description. The Execution Patterns Mind Map shows which other patterns are used by the execution patterns.

Pattern
Description
COMPARE WITH PREVIOUS VERSION
Compare the current results with the results got by running the same tests in the previous version of the Software Under Test (SUT).
EASY TO DEBUG FAILURES
Each test failure should make it obvious which test failed, what went wrong. Shouldn't take hours to figure out or require rerun of test.
EXPECT INCIDENTS
Automated scripts should be able to react to unexpected incidents without disrupting execution.
EXPECTED FAIL STATUS
Comparing to an Expected Fail outcome rather than the Expected Result enables automated failure analysis when there is a minor bug affecting all tests.
FAIL GRACEFULLY
If a test fails it should restore the system and the environment so that the successive tests are not affected.
OBJECT MAP
Declare all the GUI-Objects in the Object Map of the test automation tool.
ONE-CLICK RETEST
Retesting a specific test case should be as easy as one mouse click.
PARALLELIZE TESTS
In order to save time, run tests in parallel.
PRIORITIZE TESTS
Assign each test some kind of priority in order to be able to select easily the ones that should be run.
SKIP VOID INPUTS
Arrange for an easy way to automatically skip void inputs.
STEEL THREAD
Test a thin slice of functionality that drives the Software Under Test (SUT) from one end to the other.
UNATTENDED TEST EXECUTION
Automated tests start automatically and run unattended.
VARIABLE DELAYS
Use variable delays based on events, not fixed delays based on elapsed time.
VISUALIZE EXECUTION
When running tests show which test case is currently executing.

Back to Main Page
Back to Test Automation Patterns

Back to Design Patterns