Traditional test automation requires coding and also requires the knowledge of the selectors. Thus it can be done when the feature for the given sprint is implemented. However, it’s too late for true in-sprint test automation. Model-based testing (MBT) seems to be a better alternative when a model can be created in parallel with the code.
In the practice, however, the model should be computer-readable and should contain everything for an application to transfer the model to executable code. Thus, the modeller should know the outputs, the selectors, when to click on a button or check a box, etc. This means that traditional modelling also requires the code to be ready, though most MBT vendors state the opposite. A sad consequence is that in-sprint test automation is rather a dream. To address this issue, we introduced two-phase modelling.
Phase I. is a high-level model that is simple, implementation-independent, and can start at the beginning of each sprint. This model consists of so-called action-state steps. Each step consists of an action, optionally one or more responses, and optionally a state. An example of this is as follows: add items at least for 15 euros => check that check out is possible STATE Going to check out is possible High-level test cases are generated from the model. These tests are human-readable, and thus can be executed by testers, business analysts, etc. but not by an application. You can see that there are no superfluous details such as clicking on a coke, etc. added.
Phase II. When the application is ready, the test cases can be executed. During the execution, a low-level model and from it the test code is generated. For example, the low-level model related to the action-state step above is as follows: add items at least for 15 euros: WHEN shopping menu item IS #selected WHEN add a coke IS #clicked WHEN add a salad IS #clicked check that checkout is possible: THEN the total price IS 15 THEN checkout button IS #active The two-phase modelling is a true shift-left solution that can be used for stateful and stateless cases. A significant part of the work is making the high-level model. When the necessary code is ready, the execution of the abstract tests is fast, that’s why the in-sprint solution is possible. The related code is 10-15 times larger than the model. It's also an efficient defect prevention solution as abstract tests are good and understandable examples.
Test automation is not only fast, but it's very comfortable as testers don't need to calculate the results in advance just check them which is much easier (similarly to exploratory testing). Finally, this method is for testers as it needs test design but doesn't need coding knowledge.
SESSION REQUIREMENTS:
To execute test cases our runner with Playwright will be used.
Operating System
- Linux or
- Windows 10 and above (64-bit only)
Application
You can easily try test execution by reading the Quick Start guide.
