Our Innovation

Harmony consists of two new methods by which our tool became a unique tool significantly better than all competitors’ solutions. One of them is action-state testing which is a new way of making test models. The other is two-phase model-based testing, where a high-level model is introduced by which the models become compact and more understandable.

Action-state testing

Action-state testing is a new way of making models. You just write model steps that are natural text in any language you prefer. Each step consists of an action (input), zero, one or more responses (output), and a potential state. Each such step will be a test step. Requirements and model parts are mapped by labels (green in the figure).

Harmony will display these steps as a graph, where the left-hand side consists of the nodes and the edges, while the right-hand side consists of the text, where each step is mapped to a graph node. In this way, you don’t need to learn a new graph editor, still, you can exploit the advantage of graph visualization.
Action-state testing is significantly better than traditional state transition or any stateless solution because

Can detect more bugs
Entirely codeless
Combines stateless and stateful solutions
It can handle outputs better

For more information, read I. Forgács and A. Kovács's book.
In the figure below you can see the model of our pizza application. Considering the first step, ‘go shopping’ is an action, ‘shopping screen displayed’ is a response, and ‘NO FREE BEVERAGE’ is a state.

Two-phase model-based testing

Traditional one-phase MBT requires a model that consists of every small detail such as clicking on a button or entering a name. In other words, the model should be computer-readable. Two-phase modeling adds a high-level model that is only human-readable and therefore, consists of fewer model steps. In this way the tester can create it faster with much fewer errors as a smaller model is more understandable.

Here is an example – password change, to compare low- and high-level models.

Low-level model steps of password change:

Select the password change function
Enter old password
Enter new password
Enter new password
Submit
Logout
Press login
Enter old password
Press submit – check faulty authentication
Enter new password
Press submit – check successful authentication

High-level model step of password change

Change password - Check successful password change

Testers can execute this feature based on this single step.

When the modeler makes the high-level model, the high-level (abstract) test cases are generated. However, the tester will execute the test based on the model steps.

When the application is ready, the tester will execute the model steps. Why not the test steps? Because the number of test steps is significantly more, that is one reason for modeling instead of writing test scripts. When the tester or the developer or the business analyst executes the model steps, three things happen almost in parallel:

The low-level model step is generated. For example, the ‘go shopping’ action is transformed to ‘WHEN go shopping is clicked’.

This is only for validation purposes in case some problems occur

The executable test code is generated
The test step is executed. This makes it possible to immediately check the step. If it fails you can delete it and do it again. Therefore, there is no debugging of the tests is necessary.

The advantages of two-phase MBT:

High-level models can be created before the implementation, therefore in-sprint test automation becomes possible
It’s a very good defect prevention method as you can only make the model if the requirements are good, and most of the problems you will detect during the modeling process.
Making the high-level model is much faster as contains fewer elements
You will find more bugs
No outputs should be pre-calculated. Checking the outputs only is easier, and faster

The figure below shows the implementation process. You can manually execute the test and as a side-effect, the test is automated.