Skip to content

Scheduling tests :: Configuration based Re-execution of Failed Tests


Scheduling Feature: Support within Worksoft SaaS app for Configuration based Re-execution of Failed Tests within the Test Cycle

This is a powerful feature that will allow you to specify a configuration based on which Worksoft SaaS will auto-determine the scope of tests for the re-execution. To benefit from this feature for any test cycle within which you want to schedule the re-execution of some or all of the failed tests by specifying your configuration, just click on the actions menu for that test cycle, and click on the menu item "Re-execute Runs by Specifying a Configuration".



You can include some or all of the following criteria when specifying your configuration:
  • Execution Statuses for Failed Tests: You can optionally remove from the configuration you are specifying a subset of the statuses with which the test runs that needed to be re-executed ended with. At least one status is required. By default all failure related statuses are included.
  • Labels Attached to Failed Tests: You can optionally include in the configuration you are specifying a list of labels that can be used to determine the failed test runs that you want to be re-executed. For example, if you want all failed tests associated with specific labels within the root label “Application Modules”,  you can choose modules like "Shopping Cart", "Product Detail Page" for a storefront app in the eCommerce industry. You can include in your configuration child labels that are from more than one root label. For example, you can specify some child labels of ‘Application Modules’ and some child labels of ‘Root Cause of Failure” root label.
  • Issues Linked to Failed Tests: You can optionally include in the configuration you are specifying a list of local Issues or issues in the external Issue Tracking System (if you have integrated your project with an external system like Atlassian Jira) that can be used to determine the failed test runs that you want to be re-executed. You can search for Jira issue keys or local store issue keys or issue descriptions and build your configuration.
  • First Point of Failure Error Descriptions Linked to Failed Tests: You can optionally include in the configuration you are specifying a list of error descriptions for the first failed Instruction within your failed tests that can be used to determine the failed test runs that you want to be re-executed. Please note that you can specify more than one error description. If your error description is in the JSON format, you can use the premium editor to view the contents of the JSON properly formatted. After entering the error text, you must click on the green checkmark before you add another error description.

  • Special Configurations: Optionally, you can also make use of these parameters as well.

    • Consider for re-execution only the originally scheduled runs in the test cycles. If you don’t check this off, both the tests auto re-executed by Worksoft SaaS ML as well as the manually re-executed tests will be considered for re-execution.

    • Consider for re-execution only the reportable runs in the test cycle. If you don’t check this off, both reportable and non-reportable failed runs are considered for re-execution.


Once you have completed building your configuration, click on the ‘Preview’ button. Worksoft SaaS will fetch the test runs that meet the configuration you specified and show you a count of the test runs that match your configuration. You will also have an option to view the test runs in a new tab by clicking on the 'open in a new tab' icon. You are strongly encouraged to review the test runs and ensure that your configuration is correct.

Once you are satisfied that your configuration is correct, you should checkoff the checkbox captioned “Using 'Preview Tests', I validated that my configuration yields correct tests for re-execution” which will enable the “Re-execute Tests” button for you. Click on that button and the failed tests that match the configuration you specified will be re-executed in bulk. It’s that easy!

Ability to schedule tests from a past test cycle into a new test cycle by specifying a configuration

Yet another powerful feature that would allow you to define a configuration that will auto-determine the scope of tests executed within a past test cycle that then can be scheduled to execute within a “new test cycle”.

Here a few representative use cases where you can reap significant benefit from this new feature:

  • All tests that belong to one or more specific application modules/components have to executed as a part of new test cycle because regression has to be performed after changes/bug fixes have been deployed for those application modules/components.
  • You want to execute all tests that failed in the last (or any past) test cycle with the same root cause but as part of a new test cycle because the root cause is now resolved./li>

To benefit from this feature, just go to the "Test Cycles" home/listing screen and click on the button "Execute Test Scheduler" on the top right hand side, and choose the section item from the actions menu captioned "By selecting Test Runs from a past Test Cycle".


There are two accordions on the form that opens up.
  • You use the first accordion, you choose the past test cycle (identifier) from which you want the tests to be identified from and then specify the configuration based on which Worksoft SaaS will auto-determine the tests to be executed.

  • You use the second accordion, to define the new test cycle. In this accordion, you will specify the test cycle identifier, the planned window and the overrides, if any, for the asset capture (screenshots, videos and the logs).


You can include some or all of the following criteria when specifying your configuration in the first accordion:
  • Source Test Cycle: You must specify the identifier for the test cycle from which you want the configuration you specify below to auto-determine the tests to be picked up for execution. Only one test cycle can be selected as the source.
  • Execution Statuses for Tests: You can optionally specify one or more statuses with which the test runs that needed to be executed ended with. if you don't specify any statuses, Worksoft SaaS will include statuses.
  • Labels Attached to Tests: You can optionally include in the configuration you are specifying a list of labels that can be used to determine the test runs that you want to be executed. For example, if you want all tests associated with specific labels within the root label “Application Modules”,  you can choose modules like "Shopping Cart", "Product Detail Page" for a storefront app in the eCommerce industry. You can include in your configuration child labels that are from more than one root label. For example, you can specify some child labels of ‘Application Modules’ and some child labels of ‘Root Cause of Failure” root label.
  • Issues Linked to Failed Tests: You can optionally include in the configuration you are specifying a list of local Issues or issues in the external Issue Tracking System (if you have integrated your project with an external system like Atlassian Jira) that can be used to determine the failed test runs that you want to be re-executed. You can search for Jira issue keys or local store issue keys or issue descriptions and build your configuration.
  • First Point of Failure Error Descriptions Linked to Failed Tests: You can optionally include in the configuration you are specifying a list of error descriptions for the first failed Instruction within your failed tests that can be used to determine the failed test runs that you want to be re-executed. Please note that you can specify more than one error description. If your error description is in the JSON format, you can use the premium editor to view the contents of the JSON properly formatted. After entering the error text, you must click on the green checkmark before you add another error description.
  • Special Configurations: Optionally, you can also make use of these parameters as well.

    • Consider for execution only the originally scheduled runs in the test cycles. If you don’t check this off, both the tests auto re-executed by Worksoft SaaS ML as well as the manually re-executed tests will be considered for execution.

    • Consider for execution only the reportable runs in the test cycle. If you don’t check this off, both reportable and non-reportable failed runs are considered for execution.
    • Once you key you in the configuration, click on the 'Continue' button.

Once you have completed building your configuration in the first accordion and enter details about the new test cycle in the second accordion, click on the ‘Preview’ button. Worksoft SaaS will fetch the test runs that meet the configuration you specified and show you a count of the test runs that match your configuration. You will also have an option to view the test runs in a new tab by clicking on the 'open in a new tab' icon. You are strongly encouraged to review the test runs and ensure that your configuration is correct.


Once you are satisfied that your configuration is correct, you should checkoff the checkbox captioned “Using 'Preview Tests', I validated that my configuration yields correct tests for execution” which will enable the “Execute Tests” button for you. Click on that button and the failed tests that match the configuration you specified will be executed in bulk. It’s that easy!


Feedback and Knowledge Base