Call to Test
Adopting a modular test-case design approach is one effective way to boost reusability for large-scale test-case libraries. Instead of duplicating or copying and pasting test cases or steps, this approach emphasizes that you break them down into small, reusable pieces and then recombine the tests to achieve larger end-to-end testing scenarios.
While modularization is a bit more complex, it can lead to even greater testing efficiencies and results when used appropriately.
The most valuable test cases are broadly applicable and reusable across different cycles and releases. Test engineers should devote serious thought to designing test cases to be as specific as they need to be but also generic enough to be reused in different situations with different data inputs.
Testers can break down test cases into logical, manageable functions or modules. These modules are isolated to create independent tests that can be recombined or reused to create larger test cases to achieve complex end-to-end testing scenarios. Zephyr Enterprise allows you to nest child modules under main test cases, even with multiple levels.
Zephyr now offers the ability to include a "Call to Test" step, along with the associated test data. This enhancement enables test cases to reference and execute reusable test cases. Users can now insert a reusable test case into a parent test case using the "Call to Test" feature. Additionally, each call to a test case can be configured with its own set of test data, ensuring support for parameterized executions.
Reusing Test Cases with Call to Test
From the Test Step section of any test case, click Call to Test to reuse existing test cases.
Browse and select the desired test cases, then click Add.
The “Call to test” can only use the test case from the current release.
The test cases appear in a special step type called Call to Test.
We show the TestcaseID(Version) Name of the Testcase
TestcaseID(Version) is clickable and can navigate to the source test case
The reusable steps appear in the expanded step view.
Version Concept
Calls to test are links to the source test case. If you make changes to the source test, then the version of the source test case will increase.
Users need to sync the “Call To Test” to bring the changes done on the source test case.
Sharing Test Case
When you share a test case that includes a call to another test, the linked (called) test cases are also accessible to the user. Click Share Test Case and navigate to the folder where you have created the test case. You will see both the Test cases. Dragging any one of the test cases also shares the linked test case.
Test Execution
In Test Execution, when the User plans the Test case for the execution it will show each test step as an individual step
Each step from the “call to test” will have the [Test Case ID (Version)]
[Test Case ID (Version)] is clickable and been navigated to the source test case.
Administration
Users can configure the Maximum nested level of Call to Tests in a test case by default 3.
Using Call to Test with Parameterization
Parameterization now supports the "Call to Test" feature. This feature allows you to validate the steps in a caller test using all the test data defined in the referenced "Call to Test" test case.
Understanding Call to Test Features
The following image shows a test case that includes test data for "Browser" and "OS", which are used in its steps.
Use the Call to Test feature to include the selected test case in another test case. The new test case contains a test step and one Call to Test step in the following example. However, it does not include any test data of its own. To use this test case in another test case, using the Call to Test feature.
Expand the Call to Test section; you can view the "Test Data" associated with the steps from the called test.
Test Execution
In the "Test Execution", the test case using "Call to Test" will appear. Each Call to Test step iterates over its own test data, displaying a separate set of steps for each data entry. This allows you to validate the Call to Test steps against all available data values and to execute them independently.
For example, in a scenario where the caller test case also includes its own test data (See Image below), the caller test uses a data set named TestDataOfCaller, which contains two values: Value1 and Value2. The test case also includes one regular test step and one call-to-test step
The caller test case will have two iterations, one for each test data value. Expand the iterations, to view the Call to Test for each data value defined in the called test case. This ensures that, even when the caller test case includes its iterations, all combinations of test data from the called test case are validated comprehensively.
Error Messages
The following are the error messages you might encounter when calling to test.
The nested test case limit set in Administration is exceeded
What happens if the nested test case limit is exceeded? When the nested test case limit is exceeded in the Administration panel, you will encounter an error message during updates. The error will appear when attempting to update the version of a test case at the step level, displaying the following message: "Tree depth would be bigger than allowed."
Why am I seeing the error message?
The Call-to-Test feature only works with test cases within the same folder level. The system will block updates if the number of nested test cases exceeds the limit. For example, if you try to update a version and see the above message, it means there are too many nested test steps.
What is the limit for nested test cases?
The limit for nested test cases is set to 3 in the Administration settings. Exceeding this limit—such as having several called test steps within a single test case—will trigger the error. In Test Case ID 44694, for instance, multiple test steps were present, which violated the limit.
How can I fix the issue if the nested test case limit is exceeded?
To resolve this issue:
Remove the extra test steps to stay within the limit.
Once the called steps are removed, you can update the versions in the shared repositories.
Where does this issue occur?
This situation can only be created at the release level. Therefore, all cleanup must also be performed at the release level. Ensure that you delete the called test steps from the nested test cases.
Why is it essential to fix this?
If this issue is not resolved, the data and test steps will not be properly updated during execution, which could lead to discrepancies or errors during testing.
Encountered an error when trying to change the version because the required test does not exist
Issues updating to the latest version of a test case?
When moving to a new release or updating the version in the project repository, you can only update to the latest version of a test case if all the test cases exist at the release or project level.
Double-check for any called test cases from the Global Repository or other shared project repositories.
Ensure any test cases created at the release level have been moved up to the project level.
How do I update the called test case to the latest version?
To update a called test case to the latest version when moving to a new release, make it shared from the Global Repository; ensure all the test cases exist at the release level. For example
If your called test case (assembly 1, test case ID 44692) includes
A called test in the same folder repository.
A test was called in another folder on that release (ID 44794 and 44788).
A called test step is shared from the Global Repository; you will need to share from the Global Repository to ensure that all called test cases are at the correct folder level before updating.
How do I fix this error?
To resolve this issue, follow these steps:
Move the shared folder of test cases from the Global Repository to the project-level folder.
Once all test cases are present at the project level, you can successfully update the version.