15.4 Finding Test Cases from the Models

The purpose of the use cases is to gather requirements as a basis for abstraction. As you abstract the domain solution from the user's language used in the use cases, they may no longer be directly mappable to the models. Because the models are the final description of the system, we recommend against polishing the use cases and against spending time and effort making the use cases match the models exactly.

The test cases we build now are polished use cases that are built on the basis of the new information we gathered as we abstracted information, and constructed the models. Although the connection between the original use cases and the test cases is less straightforward, the reverse abstraction back from the test cases to the use cases is surely easier than the abstraction process that built the original models.

In turn, this reverse abstraction suggests another approach to finding test cases. Rather than work from the use cases inward to the models, we can work from the models outward to the corresponding scenarios.

Consider, for example, a statechart diagram for the Order in state 2, Adding Selection to Order. This state responds to a signal to add a selection. There are two possibilities: Either the selection already exists, or it doesn't. Each of these different execution traces corresponds to a scenario. The scenario is built from the model, rather than from the originating use case.

This process of building the test cases from the models can be automated. Tools of this type generate test vectors comprising initialization information, a signal to start things off, and a description of the final configuration of the system. This can be used to automate the entire test sequence for regression testing.