Automated test design

Harmony starts from requirements or user stories. The first step is to generate abstract test cases based on the requirements. Abstract test cases can be executed by the testers, but cannot be executed automatically. We use a new test design technique, called action-state testing where you can create a model in a very simple way. By applying this technique, you can find very tricky bugs. This technique is implementation-independent, thus they can be done in a test-first way. Harmony can generate abstract test cases from the action-state that can be validated as every stakeholder can understand them. This is a very good defect prevention method. Here is an example for the action-state model of the ATM PIN authentication:

Harmony offers additional action-state steps for the ones underlined. Adding these steps the all transition pairs test selection criterion will be satisfied. In this way, very tricky bugs can be detected.

Consider this line that an action-state step:

enter incorrect PIN => PIN refused STATE Waiting for PIN

The first part ‘enter incorrect PIN’ is an action. This action results in a response ‘PIN refused’. The system goes to state ‘Waiting for PIN’.

The next step is to make executable tests based on the action-state model. In this way, you can divide the test design process into two parts that make test automation very easy and safe.  Concrete tests are described by Harmony’s Gherkin++ syntax. Here is an example of how to make concrete test steps from the model.

Let’s start from the action-state step above:

enter incorrect PIN => PIN refused STATE Waiting for PIN

We can make the concrete test steps for the action (input) and the response (output) separately. The first concrete test referred to as a clause is the following:

enter incorrect PIN:
WHEN PIN IS wrongPIN
AND Enter PIN IS #pressed

Abstract test steps are the frame from which concrete test steps can be easily created. The so-called categories ‘PIN’ and ‘Enter PIN’ are the locators that map the test and the implementation. wrongPIN is an input value, while #pressed is a special value telling Harmony to press the button ‘Enter PIN’. Here we use an extended Gherkin language Gherkin++. The response can be implemented in the following way:

PIN refused:
THEN Message IS Incorrect PIN, try again

The figure below shows the architecture of Harmony.

Back