Modular test design is a way of promoting test case reusability and composition across a large test repository. To design modular tests, you can create a manual test where some of the steps call or include other test cases. This prevents testers from having to write the same steps over and over again in different high-level tests. Using a modular design approach, any test can become a building block of more extensive test scenarios. Still, they can also be executed individually if needed.
A called test can, in turn, also call other tests. You can compose a test scenario with up to five levels of depth.
Modular tests can also be parameterized. When calling a test, you can provide new parameter values according to the parent test data.
Upon executing, Xray will unfold all called test steps in the test run. This becomes transparent to testers as they only have to follow and execute the steps on the execution, even though test steps might come from different tests issues.
A common use case for modular tests is end-to-end testing. End-to-end tests often need to pass through the same area or component of the application before asserting the final result. With modular test design, you can reuse the tests for these common areas or components.
|
To start designing modular tests, you need to think about structure and reusability. Once you have identified the individual building blocks for a given test case, you need to consider if some blocks can originate separate test cases. If there are blocks that can be executed individually or later be reused for other test scenarios, consider creating different test issues and composing the initial test case with them.
To create a test case composed of other tests, you need to use call steps. Call steps can be interchanged with common test steps to define a test. Call steps are represented with the purple color in Xray.
To define a call test step:
A new call test step will be created.
It is possible to specify and override the parameter values for called tests. After defining the call test step, you can edit the dataset in this context.
To define the test data for a called test:
Once parameters are defined on the call test step dataset, they will appear on the step body when the step is expanded.
It is possible to map a parameter from the parent test to the called test:
Xray also supports importing steps with call test steps from the following sources:
The import wizard dialog will prompt the user to map the call test and call test parameter columns when applicable.
When exporting test steps to a CSV file, the call test steps, and their parameters will also be included on the CSV file as distinct columns.
It is also possible to expand/unfold the call test steps when exporting test steps to CSV. To archive this, the option "Expand called test steps" must be checked when exporting to CSV.
When executing tests composed of modular tests, Xray will unfold/expand all steps and replace the parameters with their resolved values.
On the step number column (located in the left of the step), an icon indicates that a step belongs to another test issue in case users need to navigate to the test.
When resolving the parameter values, Xray will try to get the parameter from the closest context. If the parameter is not found, Xray will search the parent context.
For a given parameter P within a called test step, the value of P will be resolved from the first of the following contexts where P is explicitly defined: