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 test where some of the steps call 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.

Learn more about modular tests here.

This feature will cover a common scenario where manual Test cases evolve to automated Tests. In this case, the user can either change/select the Test type to see different definitions (refer to the configuration option: Delete test definition when changing Test type) or create separate Test issues to cover all the natures for the Test.

With Test natures, we plan to make it more explicit that multiple Test definitions can coexist within the same Test case. Users will also be able to set the current definition so that Test Runs are always created using the "current" definition.

Currently, the Test Plan is composed of a static list of Test cases. This means you must explicitly add the Tests to the Test Plan. If the Tests are all known and well defined when you start your Test Plan, this is ok. However, if you are working in an agile context where a Test Plan is created for a specific sprint, Tests will only be specified during the sprint and later added to the Test Plan. This process is not ideal because users might forget to add the Tests to the Test Plan.

Dynamic Test Plans can be defined with a JQL query which will be the source for Test cases. Considering the use case described above, we can define a JQL query that will get all Tests covering requirements of a specific sprint.