Composing the Use Case Tasks

The fourth use case in Table 8.4 describes the installation of a software up- date. The corresponding task in Figure 8.4 is divided into two subtasks. The rst subtask Perform Update describes the normal update procedure, as speci- ed in the use case. However, the user can remove the USB ash drive during the update procedure. This is a typical example of exceptional behavior that must be tested during development. In particular, it is important to cover ev- ery possible situation in which the exception might occur, in order to ensure a stable state in every scenario. The second subtask Handle Removal Exception models the situation when the user removes the USB ash drive during the update procedure. The task Handle Removal Exception is only enabled when the task Perform Update is active. When the task Conrm Successful Instal- lation stops, the task Handle Removal Exception becomes disabled. However, the update procedure is disabled when the USB drive is removed during the update. This is described by the task Remove Drive When Update Active and its disable dependency to the task Perform Update. The system's reaction to the exception models the task Show Update Failed which is enabled by the task Remove Drive When Update Active.

Use case: Installation of a software update Description:

The customer or the service partner determines installed up- dates using the GUI.

1. The customer follows the instructions on the GUI and con- rms the installation of the update.

2. The customer is informed about the progress of installation. 3. Visible conrmation of successful installation is given. Prior Condition: The system has detected new updates on the USB ash drive. Post Condition: The system has detected updates on the USB ash drive.

Initiator: User

Exceptions: If the USB ash drive is removed during installation, the system should undo the update and notify the user.

Table 8.4. Use case: Software update installation.

8.2 Composing the Use Case Tasks

The previous section described each use case of the software update function- ality in TTask. In order to describe the complete software update functionality, we have to model the dependencies between these use cases. Each use case represents a specic feature. Hence, the interactions between these use cases are feature interactions. We dene these intentional feature interactions using task dependencies. Figure 8.5 shows the complete task model for the software update functionality. The subtasks that have no new dependencies are hidden for the sake of conciseness. First of all, we have to add another task Remove USB Flash Drive in order to describe the non-exceptional removal of a USB drive. The normal removal of a USB ash drive has not been described in the use case specication. The incompleteness of the specication became obvious when we simulated our task model.

Fig. 8.4. Update installation task.

8.3 Summary 121 There are three reasons for feature interaction:

1. Shared usage of the GUI: The three tasks Install Update, Show Installed Updates, and Uninstall Update are controlled via the GUI. Hence, they are all mutually exclusive because the GUI supports only the execution of one task at a time. This is modeled by the mutual exclusion pattern, which is symbolized by the choice dependency.

2. Required USB Flash Drive: The task Install Update requires a valid update on a USB ash drive. This is modeled by the enable dependency between Detect Drive with Update and Install Update. However, there are two tasks for the removal of a USB drive. One that represents the normal removal of a USB drive and one that represents the exceptional removal during the update procedure. The exceptional removal is only possible during the update procedure. Hence, it is necessary to ensure that when the update is started, only the exceptional task is enabled. This is mod- eled by the disable and enable dependency between Perform Update and Remove USB Flash Drive. Furthermore, when the task Handle Removal Ex- ception is performed, it disables Perform Update and enables Detect USB Flash Drive.

3. Installed Updates: The task Uninstall Update can only be performed if an update has already been installed. This is modeled by the enable dependency between Install Update and Uninstall Update. However, this is an example for a situation in which the current semantics of TTask do not suce. The scenario, in which the user performs two updates in a row and then uninstalls both updates consecutively, cannot be modeled with TTask. This would require the possibility to model additional precondi- tions and actions in a task, based on a common data model, for example, a counter variable, which is currently not supported in TTask.

After adding the temporal dependencies between the use case specic tasks, the task model describes all usage scenarios of the software update function- ality.

8.3 Summary

This chapter presented the rst of three case studies of task-based test case generation with TTask. This chapter focused on the rst step in task-based test case generation: modeling features and their interactions with TTask. To demonstrate TTask we created a TTask model from an existing use case specication of the software update functionality. This chapter showed that the transformation of an informal use case description into a TTask model is straightforward. Furthermore, we have seen how TTask can be used to model exceptional behavior as well as temporal dependencies between dierent use cases. In summary, this chapter showed that the eort of creating a TTask model from a given specication is reasonable. Such a TTask model enables task sequence generation in order to systematically cover the specied be- havior. The generation of task sequences and the subsequent generation of executable test scripts is the topic of the following two chapters.

9

Generating Test Cases with TTask

This chapter presents a case study in which we apply task-based test case gen- eration to a real world example. The rst objective of this study is to demon- strate our approach of task-based test case generation and test instantiation by a running example that involves all necessary steps to create executable test scripts from a task model. The second objective is to show the feasibility of our approach for a real world example from the automotive domain. In order to fulll the objectives, the case study comprises all steps of task-based test case generation:

1. Modeling features and their interactions in TTask, which has been intro- duced in Chapter 4.

2. Generation of task sequences based on test selection criteria, which were introduced in Chapter 5.

3. Renement of the generated task sequences using existing behavior mod- els, following the approach described in Chapter 6.

4. Generation of executable test scripts with AspectT (see Chapter 7).

This chapter is structured as follows. The rst section introduces the environ- ment at BMW Group in which the case study has been performed. The second section introduces the features of a real world infotainment system that are modeled using TTask. The third section presents the task sequence generation from the task model. The fourth section demonstrates test case instantiation with AspectT.