Test Model

Building test models can be used to complement and complete and possibly replace traditional test plans.

Deriving a Test Model from the Specification Model

In section 'Specification Model', execution of the specification model in order to examine its behavior has been discussed. We have seen that e.g. 'Animated Statechart' from the 'Tools' menu can be used in order to examine the statechart in animation. Even though this is a powerful tool a tester will often be interested in a more detailed specification information about particular states and modes of the execution. In other words, the tester has a different view on the system under development compared with the implementation team. In particular, testers have a special focus on robustness testing of the system under development.

Consider, for example, the question, whether negative results can be obtained from addition. The tester could formulate a test scenario: "Ensure that a negative result can be obtained from addition" in a textual test plan. On the other hand, the tester could also express this scenario directly in a test model.

In our example, a test model could be derived from the specification model by detailing some of the transitions of the specification model's statechart. In our case, the class SpecModel::TheCalc has been copied to TestModel::TheTestCalc and then the copy has been modified according to the needs of the tester, i.e. attributes have been added and the statechart has been enhanced for test generation purposes.

We assume, that the tester with his test strategy explicitly

wants all operations to be tested at least once,
wants negative, positive and zero values to be used for each operand at least once, and
wants at least one positive, one negative, and one zero result obtained from each operation execution.

A statechart for the test model that fits to the needs of our tester could look like the following one:

TestModelStatechart

It is derived from the specification statechart and has more details to capture the tester's view according to his test strategy.

Detailing transitions with subcharts

Expressing the test goal to test each operation at least once, can be done by detailing the transition chain for reception of evOperation with subchart OperationCases:

OperationCasesSubchart

Analogously, detailing the transition chains for reception of event evOperand as in subchart OperandCases

OperandCasesSubchart

expresses the test goal that negative, positive and zero values are to be used for each operand at least once. Finally, the subchart TestPlan models the test goal to obtain at least one positive, one negative, and one zero result from each operation explicitly:

TestPlanSubchart

Note: Attributes tmp_op, tmp_regno, and tmp_regval have only been added to TestModel::TheTestCalc for testing purposes.

Using this modified statechart instead of the original statechart of the specification model derives an explicit test model from the specification model by detailing. Now we have explicitly modelled our testing strategy. The objective is to cover each transition of the test model at least once. If all transitions are covered by test case execution, then all test scenarios modeled by the test model have been executed.

Note: In our example, the test model reuses the member operations of the specification model, since we derived the test model by copying the specification model. This is not neccessarily always the case. A test model could define entirely disjoint internal operations, it could make sense to modify or replace some operations. The only constraint in modelling a test model is that it adheres to the same interfaces as the specification model. Often, the specification model might be too complex for testing purposes. Or the specification model has its focus on details, which aren't of interest for testing. In these cases, a test model could also be created from scratch, only focusing on topics of interest for testing purposes.

Of course, many more detailed test goals could be explicitly formulated, such as e.g. 'test each operation with all combinations of negative, positive and zero operands'.

Test models can be build for a large variety of different aspects. They can be reduced to certain aspects of behavior, they can be used for detailing, they can possibly be built to explicitly model faulty behaviors. It might often be useful to create a set of different test models for various different purposes. They can be used to focus on parts of a specification, to model simplified workflows, to explicitly enumerate test cases. What they have in common is the reason of their creation: explicitly modelling test cases and test goals instead of writing test scenarios only in textual form. Test models are used to benefit from intuitivity and conciseness of the modelling approach also in the organization of the testing activities. Also it is much more efficient to maintain test models over time compared to traditional testing.