Automated test design

Harmony starts from requirements or user stories. The first step is to define use cases based on the requirements. Use cases are implementation-independent, thus they can be done in a test first way. Harmony can generate abstract test cases from the use cases that can be validated as every stakeholder can understand them. This is a very good defect prevention method. Here is an example for a use case:

The next step is to define the acceptance criteria based on the use cases. In this way you can divide the test design pocess into two parts that makes test automation very easy and stable. Acceptance criteria are described by Harmony’s Gherkin++ syntax. Here is an example on how to define  acceptance criteria from requirements. Note that Harmony’s acceptance criteria contain concrete values from which test cases can be generated.

In some simple  cases acceptance criteria can be made directly from the requirements. Here is an example.

Feature: Log in

R1. The user shall fill ‘Login name’, otherwise an error message: ‘Login name is required’ appears.
R2. The user shall fill ‘Password’, otherwise an error message: ‘Password is required’ appears.
R3. If either of them is wrong, then an error message: ‘Incorrect name or password’  appears.
R4. If the login is successful, then a message appears ‘Login successful!’
R5. “Exit” goes back to the main menu without logging in.

From the requirements we can extract the categories which are parameters (variables in the code) and choices (values in the code). Here we consider two requirements:

R1. The user shall fill ‘Login name‘, otherwise an error message: ‘Login name is required‘  appears.
R4. If the login is successful, then a message appears ‘Login successful!

From R1 we extract ‘Login name’ and select two choices: Smith and Wigner. This is an input category marked by (I). We also extract ‘error message’. However, in R4. We can see that this message can also be a successful login. Therefore, we name the category as Msg, which is an output i.e. (O) category. The related choices are extracted without any modification:

Login name(I): Smith; Wigner
Password(I): 2a4b6c(D); wrong-PSW
Msg(O): Login name is required; Password is required; Incorrect name or password; Login successful!
Next(A): #pressed
Here (D) means default, i.e. this choice will be generated if no other one is explicitly connected to a category.

The next step is to design acceptance criteria based on the requirements and using the categories with choices. Here we create only one acceptance criterion for the requirement R4:

WHEN Login name IS Smith
AND Password IS 2a4b6c
WHEN Next IS #pressed
THEN Msg IS Login successful!

You can see that an acceptance criterion has a name followed by test steps. A test step contains a Gherkin++ keyword, a category, a keyword ’IS’ and a choice. Everybody can understand it immediately.

This acceptance criterion explains itself. The test step WHEN Next IS #pressed expresses that after filling login name and password we should finish this process. Choices starting with ‘#’ describes the event such as click on a button.

In Harmony you can create a project designing tests for the whole application. A projects contains  features. Requirements are involved in each feature to cover them with acceptance criteria from which the tests are generated.

The figure below shows the architecture of Harmony.