This article explains about how to split a long-running Test Plan with a large number of Test Suites/Test Cases into smaller Test Plans. This would promote parallelization of the Test Plans, avoid instability in Tests due to the high memory usage of long-running threads and also reduce the feedback time.

Note: The best practice is to avoid creating a large test plan that takes more than three hours to run. Having said that even if your test coverage needs a bigger test plan we can still manage to run it without any hindrance by following the insights shared on this article.

Difficulties in splitting the Test Plan - Data Dependency

While splitting a Test Plan, we might need to transfer some data between Test Plans if there are some parameters or variables that are shared across Test Cases.

Here's an example of a similar Data Dependency between Test Cases:

Before splitting Test Plan
After splitting Test Plan

1 Test Plan(TP1) 

TP1 containing 1 Test Suite(TS1) consisting of 10 test cases(TC1, TC2, TC3, ..., TC10)

2 Test Plans(TP1 & TP2)

- TP1 containing 1 Test Suite(TS1) consisting of 5 test cases(TC1, TC2, TC3, TC4, TC5)

- TP2 containing 1 Test Suite(TS2) consisting of 5 test cases(TC6, TC7, TC8, TC9, TC10)


Let's assume TC5 has stored some runtime parameters that are being used in TC7. 

Splitting of the Test Plan into will cause failure in TC7 since the runtime parameter in TS1 doesn't have a scope in TS2 after splitting.


For this reason, we made some advancement in the Trigger Test Plan API. Trigger Test Plan API now accepts Runtime parameters as Payload. One of the advantages of this API is to transfer the data between two Test Plans.

The below article will help you get insights on how we can use a Rest API trigger to transfer run time variables to a different suite so that we can split a bigger test plan.


When to Trigger a Call

In case the Test Suite is big and we decided to split it, the API call should preferably be in the very last step of the last test case present in the test suite. It is advisable to create a new test case at last in the test suite so that things become cleaner.


How to Trigger a Call

Check the below article to know how to trigger a Test Plan using REST API Calls
Trigger / Start an execution in Testsigma remotely for CI/CD

The only additional data you need to specify in the Trigger Test Plan API is the payload defining the runtime parameters.

"runtime_data" : {
"data1":"This is the runtime data",

As you can see above, you can get the stored runtime parameter values from Test Case TC5 and use them in the form $|variable_name|.

More details:

Using Run-time Parameter Test Data in REST API Test Steps

Now, the runtime parameters that are passed in the Test Plan Trigger Call for TP2 will be available in TP2. You can use those parameters in any of the Test Cases within TP2 now.

Welcome to the era of #SmartTestAutomation