Difference between revisions of "Execution 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.
Back to Main Page
Back to Test Automation Patterns
Back to Design 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