ONE-CLICK RETEST

.................................................................................................................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

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

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

If you have also 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