• The "Worksoft SaaS Test Cycle Runner" component is responsible to create test cycle(s) and schedule one or more "Application Test Drivers", which in turn will schedule the application tests that will get run within the newly created test cycle(s).


• The "Worksoft SaaS Application Test Driver" component is responsible for scheduling one or more application tests that will get run within a specific test cycle that was already created previously.

Both the above-mentioned components can be triggered for execution in two-different ways:

• From within the Worksoft SaaS application, by clicking on a button/actions menu within the home screen of the Test Cycles module.
  
  



• Using a new service within the QaCONNECT REST API. As part of the inputs to this service, you can trigger either of these components by simply setting the value for the parameter 'componentToBeScheduled' to specify the component that you want to trigger the execution of, along with the other parameters.





Using the given API you can to do the following:


• In a single call to this service, you can trigger more than one test cycle in your project while having the flexibility to prefix or postfix your application's build identifier generated by your CI/CD system to the naming conventions as specified in the data file fed as input to the test cycle runner component of the Worksoft SaaS Scheduler. For example, you may want to simultaneously trigger the execution of both your functional regression test suite as well as your cross-platform regression test suite each time your CI/CD pipeline builds and deploys a new version of your application. When this happens you typically want the build identifier for new build to be appended to or prepended to test cycle naming conventions that include words like "Functional Test Suite" and "Cross-Platform Test Suite. To do this you pass the build identifier into the parameter "testCycleIdentifier" and a value into the parameter "testCycleIdentifierQualifier" of either "02" (for prefixing the build identifier) or "03" (for suffixing the build identifier).
  
  
• You can apply a different planned start and end windows for each of the test cycles you schedule within a single call to the service. For example, may be you want the planned window to be different for your functional regression test suite and your cross-platform regression test suite. You can do so by feeding in the appropriate value for the parameters "plannedWindowStartDateTime" and "plannedWindowEndDateTime".
  
  
• Optionally, for each test cycle you schedule, you can apply a data filter to the file name you pass into the parameter "dataFileName" and feed in the values for any dynamic variables used within that data filter. A dynamic variable is either a user-defined variable or a local variable that is used within a data filter. You can avail this feature by using the parameters "dataFilterName" and "dataFilterUserDefinedVariableValueOverrides". This feature will allow you to maintain a smaller (may be even a single) number of data files within the test cycle runner inputs, application test driver inputs and the application test batch dependency configuration. A specific use case will illustrate the power of this feature to you. Let us say, you have a single data file with the test cycle runner inputs: the first row corresponds to your functional regression test suite, the second row corresponds to your cross-platform regression test suite, and the third row corresponds to a suite of tests one of the automation developers executes within the Worksoft SaaS UI because he/she is debugging some issues with the tests for a specific application module. From the CI/CD pipeline when making a single call to the scheduler service, you can feed the first set of values for the section "testCycleRunnersInputConfigurationList" to be the name of that single data file and a data filter name when applied will match the first row of the data file, and as second set of values the the name of that single data file and a data filter name when applied will match the second row of the data file. This third row will be ignored when the service call is made from the CI/CD pipeline.
  
  
• In addition to defining the feed inputs for the Test Cycle Runner component by using the parameters within the section "testCycleRunnersInputConfigurationList" you can optionally feed inputs to the the Application Test Driver component as well by populating parameters within the "applicationTestDriversInputConfigurationList" section.
  

The powerful features described above are also supported within the Test Cycles module home screen within the Worksoft SaaS application. Within the test cycles screen, when you trigger the "Test Cycle Runner" component by clicking on the "Execute Test Scheduler" button on the top right hand side, you will now see two or three accordion sections based on the contract you have with Worksoft. If you have subscribed for Performance Testing, you will see three accordions else two of them. You can find details pertaining to Performance Testing cycles here:

Test Cycle Runner inputs: In this section, you must select:

• One ore more data files that have the inputs to the test cycle runner


• Optionally, a data filter to be applied on the selected data file(s)


• If a data filter was selected and if it has dynamic variables (either user-defined variables or local variables), then you must enter the values for those variables


• Optionally, enter the override values for the test cycle's planned window start datetime and end datetime


• Optionally, feed in either the complete test cycle identifier or a string that will be either prefixed or suffixed to the test cycle identifier name string configured within the selected data file


• In addition, you will also be able to use two checkboxes to let the values of the user-defined variables used within the application tests to be read from the MyWorkspace of the user account that is using the UI based scheduler component and whether or not to immediately preprocess the application test runs being scheduled when the actual datetime of execution is in the future



Application Test Driver Inputs: In this section, you can optionally specify the name of the data filter you want to get applied to the application test driver inputs data file(s) that will be auto-selected by Worksoft SaaS based on the rows of the test cycle runner inputs data file(s) fed into the Worksoft SaaS Scheduler. Again, if a data filter was selected in this accordion section and if it has dynamic variables (either user-defined variables or local variables), then you must enter the values for those variables.




Similarly, when you trigger the "Application Test Driver" component by clicking on the "Execute Test Scheduler" menu from the actions menu of a specific test cycle, you can optionally specify the name of the data filter you want to get applied to the application test driver inputs data file that you must select. Again, if a data filter was selected in this section form and if it has dynamic variables (either user-defined variables or local variables), then you must enter the values for those variables.

Data Files

The components "Test Cycle Runner" and the "Application Test Driver" will need as input two or three data files that you prepare/maintain within your project that belong to the following (locked-from-edit/read-only) data definitions. These data definitions are pre-loaded into every single project at the time of creation of the project.

• Test Cycle Runner Inputs: . This data definition specifies the structure for the data file(s) that will contain the inputs to the "Worksoft SaaS Test Cycle Runner" component that is responsible to create test cycle(s) and schedule one or more "Application Test Drivers", which in turn will schedule the application tests that will get run within the newly created test cycle(s). To learn more details about the information that can be included in the data files that correspond to this data definition, please click here.


• Application Test Driver Inputs: This data definition specifies the structure for the data file(s) that will contain the inputs to the "Worksoft SaaS Application Test Driver" component that is responsible to schedule one or more application tests that will get run within a specific test cycle. To learn more details about the information that can be included in the data files that correspond to this data definition, please click here.


• Application Test Batch Dependency Configuration: This data definition specifies the structure for the data file(s) that will contain the configuration details for batch dependencies which are used to control the flow of executions within a test cycle.
  
  Using batch dependencies you can accomplish conditional triggering of the execution of blocks of tests. To learn more details about the information that can be included in the data files that correspond to this data definition, please click here.
  
  For example, you can trigger the execution of batch of tests in one testing platform only if the execution of the tests in a different testing platform passes. Another example use case is triggering full regression test suite in a subsequent batch only if the smoke suite of tests pass in an earlier batch.