Difference between revisions of "ONE-CLICK RETEST"

From Test Automation Patterns
Jump to navigation Jump to search
m (Corrected link to INTERDEPENDENT TESTS)
Line 14: Line 14:
 
=<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 FAILURE ANALYSIS]]</span>''<br /> ''<span style="font-size: 16px">[[MANUAL INTERVENTIONS]]</span>''
 
''<span style="font-size: 16px">[[INEFFICIENT FAILURE ANALYSIS]]</span>''<br /> ''<span style="font-size: 16px">[[MANUAL INTERVENTIONS]]</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: 16px">Here two examples from Seretta:</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: 16px">Here two examples from Seretta:</span>
=<span style="font-size: 16px">Example 1</span>=
+
 
 +
<span style="font-size: 16px">Example 1:</span>
 
<span style="font-size: 16px">We have written some quite long test suites and even if we do have prioritisation in place (we distinguish between High, Medium, Low and Irrelevant), it took time to change the priorities so that only the one test case could be run for retest. </span><br /> <span style="font-size: 16px">One of our typical test suites has a structure like this:</span><br /> <br /> <span style="color: #ff0000; font-size: 16px">Business Process: My Test suite </span><br /> <span style="color: #ff0000; font-size: 16px"> Business Case: Business Case 1</span><br /> <span style="color: #ff0000; font-size: 16px">Test Case: Test Case 1.1</span><br />  
 
<span style="font-size: 16px">We have written some quite long test suites and even if we do have prioritisation in place (we distinguish between High, Medium, Low and Irrelevant), it took time to change the priorities so that only the one test case could be run for retest. </span><br /> <span style="font-size: 16px">One of our typical test suites has a structure like this:</span><br /> <br /> <span style="color: #ff0000; font-size: 16px">Business Process: My Test suite </span><br /> <span style="color: #ff0000; font-size: 16px"> Business Case: Business Case 1</span><br /> <span style="color: #ff0000; font-size: 16px">Test Case: Test Case 1.1</span><br />  
 
* <span style="color: #ff0000; font-size: 16px">Test Procedure: Test procedure 1.1.1</span>
 
* <span style="color: #ff0000; font-size: 16px">Test Procedure: Test procedure 1.1.1</span>
Line 78: Line 80:
 
* <span style="color: #0000ff; font-size: 16px"> Test Procedure: Test procedure 2.2.5</span>
 
* <span style="color: #0000ff; font-size: 16px"> Test Procedure: Test procedure 2.2.5</span>
 
* <span style="color: #0000ff; font-size: 16px"> Test Procedure: Test procedure 2.2.6</span>
 
* <span style="color: #0000ff; font-size: 16px"> Test Procedure: Test procedure 2.2.6</span>
<span style="font-size: 16px">………………………………………………</span><br />  
+
<span style="font-size: 16px">………………………………………………</span><br /> <br /> <br />  
=<span style="font-size: 16px">Example 2</span>=
+
 
 +
 
 +
<span style="font-size: 16px">Example 2:</span>
 
<span style="font-size: 16px">Lets take our test suite from above and lets imagine that any test case can can only be executed after Test case 1.1.</span><br /> <span style="font-size: 16px">In this case we could set this parameter to "Always" for Test Case 1.1 and we leave the rest as defined in Example 1. Now when we execute Test Case 1.2 the system will always execute first Test Case 1.1!</span><br /> <br /> <span style="color: #00ff00; font-size: 16px">Business Process: My Test suite </span><br /> <span style="color: #00ff00; font-size: 16px"> Business Case: Business Case 1</span><br /> <span style="color: #ff0000; font-size: 16px"> Test Case: Test Case 1.1</span><br />  
 
<span style="font-size: 16px">Lets take our test suite from above and lets imagine that any test case can can only be executed after Test case 1.1.</span><br /> <span style="font-size: 16px">In this case we could set this parameter to "Always" for Test Case 1.1 and we leave the rest as defined in Example 1. Now when we execute Test Case 1.2 the system will always execute first Test Case 1.1!</span><br /> <br /> <span style="color: #00ff00; font-size: 16px">Business Process: My Test suite </span><br /> <span style="color: #00ff00; font-size: 16px"> Business Case: Business Case 1</span><br /> <span style="color: #ff0000; font-size: 16px"> Test Case: Test Case 1.1</span><br />  
 
* <span style="color: #0000ff; font-size: 16px"> Test Procedure: Test procedure 1.1.1</span>
 
* <span style="color: #0000ff; font-size: 16px"> Test Procedure: Test procedure 1.1.1</span>

Revision as of 15:05, 26 June 2018

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

Pattern summary

Retesting a specific test case should be as easy as one mouse click

Category

Execution

Context

This pattern helps to efficiently retest previously failed tests.
This works if the system is state-less, i.e. you don't get different results depending on the state of something.

Description

Make the retest of a specific test case as easy as possible. If you have a TEST AUTOMATION FRAMEWORK to support you, you should be able to select the test case and run it literally with one mouse click

Implementation

If you can PRIORITIZE TESTS, it will be relatively easy to change the priorities to select only the desired test case. If you add another level of prioritization, you can reduce this effort even more (see Example 1)

Recommendations

An extra level of prioritization allows you to use this pattern even if you have INTERDEPENDENT TEST CASES (see Example 2)

Issues addressed by this pattern

INEFFICIENT FAILURE ANALYSIS
MANUAL INTERVENTIONS

Experiences

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!

Here two examples from Seretta:

Example 1: We have written some quite long test suites and even if we do have prioritisation in place (we distinguish between High, Medium, Low and Irrelevant), it took time to change the priorities so that only the one test case could be run for retest.
One of our typical test suites has a structure like this:

Business Process: My Test suite
Business Case: Business Case 1
Test Case: Test Case 1.1

  • Test Procedure: Test procedure 1.1.1
  • Test Procedure: Test procedure 1.1.2
  • Test Procedure: Test procedure 1.1.3
  • Test Procedure: Test procedure 1.1.4
  • Test Procedure: Test procedure 1.1.5
  • Test Procedure: Test procedure 1.1.6

Test Case: Test Case 1.2

  • Test Procedure: Test procedure 1.2.1
  • Test Procedure: Test procedure 1.2.2
  • Test Procedure: Test procedure 1.2.3
  • Test Procedure: Test procedure 1.2.4
  • Test Procedure: Test procedure 1.2.5
  • Test Procedure: Test procedure 1.2.6

………………………………………………
Business Case: Business Case 2
Test Case: Test Case 2.1

  • Test Procedure: Test procedure 2.1.1
  • Test Procedure: Test procedure 2.1.2
  • Test Procedure: Test procedure 2.1.3
  • Test Procedure: Test procedure 2.1.4
  • Test Procedure: Test procedure 2.1.5
  • Test Procedure: Test procedure 2.1.6

Test Case: Test Case 2.2

  • Test Procedure: Test procedure 2.2.1
  • Test Procedure: Test procedure 2.2.2
  • Test Procedure: Test procedure 2.2.3
  • Test Procedure: Test procedure 2.2.4
  • Test Procedure: Test procedure 2.2.5
  • Test Procedure: Test procedure 2.2.6


………………………………………………

Business Process and Business Case are just containers that allow us to categorize correctly the test cases. The test cases are composed of test procedures that call the actual test scripts.
The objects are colour coded to represent the priority. In this example all test procedures have priority High.
If we wanted to execute only Test Case 2.1 we would have to set the priority of all the other test cases to Medium, then execute the test case and finally not forget to reset the priorities for the next complete test run. It works, but it takes time and it’s error prone.
To solve this problem we introduced a second layer of prioritisation, which we called “To be executed”. We can choose from:

  • On request
  • With parent object
  • Always
  • Never


Now you can set this parameter to "On Request" for all objects, with the exception of test procedures. Test procedures are set to "With parent object". To select Test case 2.1 for execution we now only have to select the test case and click on the execution menu "To be executed". We don’t need to change any priority!

Business Process: My Test suite
Business Case: Business Case 1
Test Case: Test Case 1.1

  • Test Procedure: Test procedure 1.1.1
  • Test Procedure: Test procedure 1.1.2
  • Test Procedure: Test procedure 1.1.3
  • Test Procedure: Test procedure 1.1.4
  • Test Procedure: Test procedure 1.1.5
  • Test Procedure: Test procedure 1.1.6

Test Case: Test Case 1.2

  • Test Procedure: Test procedure 1.2.1
  • Test Procedure: Test procedure 1.2.2
  • Test Procedure: Test procedure 1.2.3
  • Test Procedure: Test procedure 1.2.4
  • Test Procedure: Test procedure 1.2.5
  • Test Procedure: Test procedure 1.2.6

………………………………………………
Business Case: Business Case 2
Test Case: Test Case 2.1

  • Test Procedure: Test procedure 2.1.1
  • Test Procedure: Test procedure 2.1.2
  • Test Procedure: Test procedure 2.1.3
  • Test Procedure: Test procedure 2.1.4
  • Test Procedure: Test procedure 2.1.5
  • Test Procedure: Test procedure 2.1.6

Test Case: Test Case 2.2

  • Test Procedure: Test procedure 2.2.1
  • Test Procedure: Test procedure 2.2.2
  • Test Procedure: Test procedure 2.2.3
  • Test Procedure: Test procedure 2.2.4
  • Test Procedure: Test procedure 2.2.5
  • Test Procedure: Test procedure 2.2.6

………………………………………………



Example 2: Lets take our test suite from above and lets imagine that any test case can can only be executed after Test case 1.1.
In this case we could set this parameter to "Always" for Test Case 1.1 and we leave the rest as defined in Example 1. Now when we execute Test Case 1.2 the system will always execute first Test Case 1.1!

Business Process: My Test suite
Business Case: Business Case 1
Test Case: Test Case 1.1

  • Test Procedure: Test procedure 1.1.1
  • Test Procedure: Test procedure 1.1.2
  • Test Procedure: Test procedure 1.1.3
  • Test Procedure: Test procedure 1.1.4
  • Test Procedure: Test procedure 1.1.5
  • Test Procedure: Test procedure 1.1.6

Test Case: Test Case 1.2

  • Test Procedure: Test procedure 1.2.1
  • Test Procedure: Test procedure 1.2.2
  • Test Procedure: Test procedure 1.2.3
  • Test Procedure: Test procedure 1.2.4
  • Test Procedure: Test procedure 1.2.5
  • Test Procedure: Test procedure 1.2.6


………………………………………………

Business Case: Business Case 2
Test Case: Test Case 2.1

  • Test Procedure: Test procedure 2.1.1
  • Test Procedure: Test procedure 2.1.2
  • Test Procedure: Test procedure 2.1.3
  • Test Procedure: Test procedure 2.1.4
  • Test Procedure: Test procedure 2.1.5
  • Test Procedure: Test procedure 2.1.6

Test Case: Test Case 2.2

  • Test Procedure: Test procedure 2.2.1
  • Test Procedure: Test procedure 2.2.2
  • Test Procedure: Test procedure 2.2.3
  • Test Procedure: Test procedure 2.2.4
  • Test Procedure: Test procedure 2.2.5
  • Test Procedure: Test procedure 2.2.6

………………………………………………

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