How to Build a Model

In this documentation article, learn how to build a Model in Test Modeller.

A model must have at least one Start Node, and one End Node. Each block must be in a path that begins and ends with a Start and End point.

All actions except for Pools must be connected to another action by arrows or "edges”. Together, these actions must form paths between Start and End points. To move these actions, hover over the text and your cursor will change to a four-directional arrow, this allows the actions to be moved around the canvas.

To connect actions other than Pools, click inside the block and drag the mouse to the following block:
 

Arrows are directional. Two Tasks connected by an arrow denote a linear step in a system's logic, either activities performed by a user or internal to the logic of the system itself.

Tasks can have multiple Edges. This denotes the different routes through a system's logic, determined for instance by data entered or by processes for error handling.

A "Condition" block functions like an "IF" statement, posing a condition that Tasks performed by a user or the system can fulfil. These Tasks might lead to further Tasks being performed by the system, or actions expected of the user. Alternatively, a condition can lead to further conditions.

In the abstract, a Model of a system under test might reflect the linear, cause-and-effect logic of a system as follows:

The completed models should be directional graphs through a system's logic, from Start events to End events. Logical processes or Tasks are ordered sequentially as steps between the start and end-point, including decisions. The "paths" from start to end points are equivalent to possible tests, with each "Task" block a test step. These tests are routes through the system's logic in the form "IF this, THEN that, THEN that…".

Example Model in Test Modeller

The following is a simplified example of a model built to test a log-in page's authentication. Users must enter a valid username and password, and then they should be authenticated. Any other combination of valid or invalid username and password should lead to the user not being authenticated.

In terms of cause-and-effect, IF-THEN logic discussed above, this model presents the following paths between the start and possible end points:

1. IF(user enters a valid username AND a valid password), THEN user is valid and Authenticated.
2. IF(user enters an invalid username AND a valid password), THEN user is invalid and is not Authenticated.
3. IF(user enters an invalid username AND a invalid password), THEN user is invalid and is not Authenticated.
4. IF(user enters a valid username AND a invalid password), THEN user is invalid and is not Authenticated.

These paths are equivalent to test cases. They can be represented in the following decision table: