Reusable Subflows

6.1 Creating Reusable Subflows

In this Test Modeller 101 Tutorial on creating reusable processes, you’ll see the benefit is in reducing manual effort and enabling scalability, through connecting existing models and seeing them as components for use in a variety of Scenarios. A typical example might be a log-in process, and this reuse extends to Test Data.

In the example, the prerequisite is to have at least 2 models created. These Subprocesses are imported through Test Modeller’s Explorer window into an end-to-end flow.

You’ll see the use of End Nodes too, that on each import of a subprocess to an end-to-end Test Modeller prompts which node from the previous Subprocess to chain to. There are 2 flows through the model, one leading to a happy validated end point but also a variant of an error, which are both viable outcomes that require testing.  

6.2 Parameterising Subprocess Data

In this Test Modeller 101 Tutorial on parameterising subprocess data, you’ll see how Subflows can pass or take Variables to one another or overwrite them, depending on how these have been Exposed and Mapped.

The example here is of a Username and Password, the first Subflow shows the process for creating a Username and Password, and the second model is for using this created Username and Password as login credentials.

So, you’ll see how Variables can be sent and modified from one subprocess to another. In terms of previewing which nodes you may want to pass down Variables, it’s possible to expand and collapse the view a subprocess within the Master Model.

Using the Data Variable pane you’ll see options to Expose predefined Variables, and using these as Mapped Outputs these Parameters go from one Subprocess to the next.

6.3 Tagging Subprocesses for Test Case Generation

In this Test Modeller 101 Tutorial, you'll be defining test coverage of the Model as both exhaustive but also low coverage to limit or expand the number of useful test cases generated, which involves laying Tags over specific Subflows.

You’ll see use of Coverage Profiles and how switching between each show different test case outcomes. The benefit of this, is that you can test a system component vigorously while in-sprint, and switch to a low Coverage Profile once tested.

For each level of testing coverage required, you’ll be able to attribute Tags to control how vigorously each component is tested. In the example, 26 paths or test cases get generated at the highest-level defined Coverage Profile, whilst this is reduced to 16 paths or test cases when switching to the low coverage profile.