We show the modeling by applying a feature of the Glossary app. We first create a state that could be used for all the features. Here, we use it for the cheat sheet for implementation.
R1: When the term details are displayed for an item in a result list of terms, the user should be able to navigate to the details of the Next term or the previous term in the list with one click ("Next" and "Previous" buttons).
R2: The user should be able to go back to the search result list by pressing the up arrow (Up button).
R3: The navigation buttons shall have mouseover tooltips ("Next term in the list" for Next, "Previous term in the list" for Previous, and "Result list" for Up buttons)
R4a: The Next button shall only be active if there is a next term in the list, i.e., for the last term of the list, the Next button shall not be active (or not displayed).
R4b: The Previous button shall only be active if there is a previous term in the list, i.e., for the first term of the list, Previous button shall not be active (or not displayed).
R5a: If the user leaves the term details for the selected term, the buttons will disappear.
R5b: If the user changes the language, the buttons are inactive (disabled).
The first step is to create a project, then a feature. The next step is to create the requirements. The feature is the navigation among terms. Here are the requirements:
Before creating the model, you should add the URL https://glossary.istqb.org/ in the Parameters window. You should also modify the Timeout to 12 seconds.
Now you can start designing the tests, i.e., the action-state model. The first step is to accept cookies. All the test cases in this cheat sheet need this acceptance, therefore, we created a simple feature ’Start Glossary’. In this feature, we set a state that can be used elsewhere. After selecting ’ +Start designing tests’, type ’Start glossary’ as the first action. You can add a response by pressing the right arrow button (or clicking on the right arrow icon). The response can be ’ Glossary is ready to start’. Finally, clicking on the state icon
the state can be ’GLOSSARY OPEN’.
Generally, when you test a feature, the program should be in the state where the feature starts. A well-known example is that a user should be logged in. However, states can be used not only for preconditions. You can build new states based on former states and inserting new steps. For example, during testing Harmony, we created a state ‘Registered’, then based on it, ‘Project exists’, then ‘Feature exists’. You can also use states in a sequence if they are independent. For example, you can use state ‘Logged in’, ‘Personnel data filled’, and ‘Authorization data access’. ‘Logged in’ should be the first; the others can be in any order. In this way, complicated tests can be easily created.
Modeling requirement #1
First, click on the precondition icon:
