In this chapter, we show, how to make a model step by step. Based on this, you can make your own model either for our or for your own application.
The example
We consider a simple example whose only goal is to demonstrate modeling including test states. The application is ‘Pizza shopping’ for which we selected the following requirements:
R1. In a Pizza Ordering service foods/beverages are offered (the prices are in euros):
Pizza Mexicana 7
Pizza Rucola XXL 14
Pizza Chicken 8.5
Coke 2
Beer 3
R2. The marketing department has a concrete idea about the GUI (see below). The user can increase the ordered number of items by pressing "+" next to the item.
R3. The user can delete (set to 0) the ordered number of items by pressing “x “ next to the item.
R4. If the total price excluding beverages reaches 30 euros for the first time, a present beverage is offered to the customer. The user can select one free Coke or beer which is added to the previously ordered beverages. ‘Free coke’ or ‘Free beer’ is displayed when a free beverage is on the ordered list. The free beverage cannot be changed from Coke to beer or vice versa.
R5. If the customer deletes food items and the price of pizzas goes below 30 euros, then the free beverage has been withdrawn. Adding the pizzas back the free beverage is also given back.
R6. The customer can delete the free beverage. When the non-beverage price condition holds and she adds the same beverage again, it remains free.
Here is the case, when a free beer has been selected:
Making the model
By applying action-state modeling you can make the model step by step and extend it when necessary. Here we will cover the requirements, however, remember that by covering the requirements you will not find all the bugs. Based on our research, only about 70% of the potential bugs can be found. We note that by applying stateless models, only 40% are found a much worse result.
It’s important to know that you can cover the requirements in any order. Hence we concentrate on the ‘difficult’ requirements that are R4-R6, and when we cover them, we also cover the others.
Modeling R4
Let’s cover R4. To do this we should add pizzas so that their prices reach EUR 30. Despite other modeling tools, here you don’t need to specify which pizzas you add, just write a high-level action. Similarly, you don’t need to calculate the prices of the pizzas at this stage. The initial model:
The initial state ‘SHOPPING’ is a state where the screen for shopping appears. The next step is when we select either a beer or a Coke. Therefore, here we should have a fork starting from our existing step by selecting fork after (Alt + Enter):
Then let’s fill out the actions and add responses and states:
Modeling R5
With this, we covered R4. Now let’s continue with R5. It’s easy, just delete some pizzas at both branches, then add some others back:
You can see that some actions, responses, and states are repeated. This will accelerate the next phase, test execution, and automation.
Modeling R6
Now let’s cover R6. Here we should delete the free beverage and add it again. However, we should add the other type of beverage instead of the deleted one to see that the other beverage will not be free. We should start new branches from the steps with actions ‘select beer’ and ‘select Coke’, respectively.
The question is the state after deleting the free beverage. Here the beverage is not withdrawn, but it doesn’t exist anymore, so we can make a common state ‘free beer/Coke lost’. However, we should insert states so that requirements be covered by applying the simplest test selection criterion which is to cover each edge (action). Therefore, we should introduce a new state: ‘free beer/Coke removed’. With this, the model becomes the following:
However, there is a problem: the response ‘beer/Coke is freely added’ happens twice. This means that they should be the same. However, we should check the total price to see that the beverage is really free. Because covering the requirement R6 we added the other beverage that is not free, the total prices will be different. We should modify the second occurrence to ‘beer/Coke is freely added again’:
Now we check the remaining requirements. We added both Cokes and beers, and we also can add two types of pizzas first and the third one when we give pizzas back. We also deleted some pizzas and beverages. In this way, we only need to modify the action ‘add pizzas again’ to ‘add different pizzas back’. With this, we covered the requirements.
The graph is very understandable, you can immediately observe that there are four test cases here.
Statechart
The generated state chart is as follows.
To detect almost all the defects you should cover each possible transaction starting from each state. For example, an action for deleting a pizza from the state ‘FREE BEVERAGE OFFERED’ is missing. This action would arrive at a new state ‘no free beverage offered’. Statechart is a good feature to make our model compete.