EN 
DE User stories and use-case-based test case generation
Author: Alexander Huwaldt, Laser & Co. Solutions
Contribution – Embedded Software Engineering Congress 2015
The starting point and scope of the methodology presented here are user-centered functional system requirements and the resulting usage scenarios, known as user stories, for embedded systems. UML use case and activity diagrams were used for the notation. The system requirements thus captured serve as the basis for the automatic generation of test cases for system and acceptance testing.
The UML use case diagram is suitable for capturing and visualizing system requirements with a high degree of granularity according to a simple, almost minimalist scheme. The user of the system is the central focus (Use Case Driven Design, see accompanying figure)., PDF).
In this form, the use case represents the system's usage scenario as a human-machine interaction. The usage scenario itself is refined as an activity model. Ideally, exactly one typical usage scenario can be assigned to each system requirement. However, it is also possible to add further secondary scenarios to a primary usage scenario to reduce the complexity of the visualization. The interaction is recorded as alternating activities and decisions between the user and the system. This results in a user-focused process and a user story. The functional requirements for the system are systematically elaborated in this process. The activity model should be subdivided into only two partitions – the user and the system. The recorded system functions must represent system behavior that is later visible to the user and thus verifiable (see the corresponding figure)., PDF).
The activity model should be formulated in such a way that it remains easily understandable for a typical system user. Therefore, only a small subset of the possible notation elements from the UML activity diagram is required. In addition to generating transparent test scenarios, activity models have also proven valuable as user documentation. Changes to system requirements must always be incorporated into the model via use cases and user stories. Test scenarios can be generated from the existing model with varying levels of coverage. The test designer can then sort and prioritize the generated scenarios and, if necessary, add preconditions and constraints to the tests.
The following case study briefly demonstrates the application of the methodology and tools. The system presented is a plant for filling insulating windows with noble gas. Although the model has been simplified, it represents the essential elements. First, the schematic structure of the plant as a SysML block definition diagram. Knowledge of the system structure is essential for formulating the user stories. The "visible" system behavior to be formulated later cannot be reduced solely to visual and audible indicators. For example, the solenoid valves, which operate audibly, are also quite suitable for making system behavior verifiable for the tester (see the accompanying figure)., PDF).
The user perspective, represented at the highest level of abstraction, is added to the system structure model: the use case diagram. This forms the starting point for further refining the usage scenarios. For this purpose, the use cases are refined as activity diagrams (see the corresponding figure)., PDF).
The following diagram (see accompanying illustration, PDFFigure 1 shows a sufficiently complete usage scenario for the system. To reduce complexity, the case of user interruption of the filling process could be further separated as a secondary scenario if required.
From this activity model, the possible paths with a predefined degree of coverage are now automatically determined. The different paths can be visualized as layers in the tool used. The reduced-size representations show an excerpt of the determined control flow paths of the above process model (see corresponding figure)., PDF).
For the test designer, the identified paths form the basis for creating the test documents. They can prioritize the primary or user-typical paths by sorting them and adding further test conditions. In the next step, they generate a presentation of the test cases and test scenarios from this prepared material, for example, as text documents or HTML. Other output formats, such as XML for transferring the test cases to other tools, are also possible. The test scenario is presented both in textual and graphical form. The following examples show possible presentation formats.
Technician: turns on the system
FGFS: System is booting up
FGFS: Goes into standby mode, LED indicator off
Technician: [wants to start the filling process] / presses START
FGFS: Automatically calibrate the system
FGFS: Start filling process, LED „fill“ on
FGFS: 20s forced filling
FGFS: Determine fill level
FGFS: [Gas content determined] / Display fill level
FGFS: [Pure gas detected, disc full] / End filling process
FGFS: goes into standby mode, LED indicator off
Technician: [wants to switch off the system] / switches off the system
(see accompanying illustration, PDF).
Technician: Turn on the system
FGFS: System is booting up
FGFS: Goes into standby mode, LED indicator off
Technician: [wants to start the filling process] / presses START
FGFS: Automatically calibrate the system
FGFS: Start filling process, LED „fill“ on
FGFS: 20s forced filling
FGFS: Determine fill level
FGFS: [Gas content determined] / Display fill level
Technician: [wants to cancel the filling process] / presses STOP
FGFS: Finish filling process, LED „fill“ off
FGFS: Goes into standby mode, LED indicator off
Technician: [wants to switch off the system] / switches off the system
(see accompanying illustration, PDF).
Technician: Turn on the system
FGFS: System is booting up
FGFS: Goes into standby mode, LED indicator off
Technician: [wants to start the filling process] / presses START
FGFS: Automatically calibrate the system
FGFS: Start filling process, LED „fill“ on
FGFS: 20s forced filling
FGFS: Determine fill level
FGFS: [Gas content determined] / Display fill level
FGFS: [Detected maximum filling time exceeded] / End filling process
FGFS: Goes into standby mode, LED indicator off
Technician: [wants to switch off the system] / switches off the system
(see accompanying illustration, PDF).
The presented methodology is characterized by easily understandable and simple-to-notate representations. It deliberately uses only a few UML modeling elements. This minimizes the learning curve and ensures a high level of acceptance among non-UML users, such as clients, engineers, etc. With appropriate tool support and available generators, in addition to the clear diagrams, further representational forms such as lists, tables, matrices for system requirements, system functions, test scenarios, and user documentation can be derived from the models created once.
Testing, Quality & Debugging – Our Training & Coaching
Do you want to bring yourself up to date with the latest technology?
Then find out more here MircoConsult offers training courses/seminars/workshops and individual coaching on the topics of testing, quality & debugging.
Training & coaching on the other topics in our portfolio can be found here. here.
Testing, Quality & Debug – Expertise
Valuable expertise on the topics of testing, quality & debugging is available. here Available for you to download free of charge.
You can find expertise on other topics in our portfolio here. here.
