12 GHERKIN-BASED MBT

Most MBT tools are commercial and rather expensive (Micskei, 2017). In this book, we only consider free tools. Fortunately, there are some free tools available. We selected one text-based and one graphical tool so that you can try and use them. In this chapter, we review a Gherkin-based modelling language and the related tool, Harmony (available at https://trial.harmony.ac). This tool is easy to learn and use and writing test code is not necessary (scriptless solution). Recall that independently of being graphical or textual, the main characteristics of test models to consider are as follows:

Harmony has been developed to take into account these characteristics as much as possible. Also, Harmony supports the test-first method, which is very important since the generated test cases are implementation independent, similar to a good specification/feature/user story. For example, if only the code changes are improving the GUI, then the designed test cases will not change, and only the automated executable test scripts will be modified. On the other hand, if the specification has been changed, then so is the model, and the affected test cases are regenerated. In this case, the tester knows the modified/new test cases and the maintenance will be easier, simpler and cheaper.

The tool’s modelling language starts from and extends the Gherkin syntax, which was originally used in the BDD tool Cucumber (Wynne and Hellesøy, 2012) to define test cases. The Gherkin syntax defining a test case is the following:

In this way, we can create test cases but not models. Harmony is based on the category-partition method (Ostrand and Balcer, 1988), which is a strategy for designing and specifying functional tests. By extending the Gherkin syntax and improving category-partitioning, the result is a modelling language.

Instead of scenarios, the basic element of the modelling language is the feature – a given part of the project’s specification, represented by requirements or user stories. A Harmony model contains three basic elements: categories, choices and acceptance criteria (AC). A category is a precondition, an input or an output entity taken from the feature description. For example, ‘logged in’ is a precondition, ‘PIN code’ is input and ‘total price of books’ is an output category. Each category contains one or more choices, which are abstract or real values. For example, ‘logged in’ can be true or false, ‘PIN code’ can be correct or incorrect (abstract) or 7723 (real). Finally, ‘total price of books’ can be quite a few, very high (abstract) or 43.99 (real).

When the categories and the choices have been selected, the next step is to set the necessary AC based on the requirements. Acceptance criteria are dependences among input (including preconditions) and output choices. AC are described by an extended Gherkin syntax. For example, the constraint between a valid login name, password and the login status can be expressed in Harmony as:

WHEN login name IS Smith AND password IS 77abTH55 THEN login status IS logged

In Harmony the keywords are uppercase letters, and all three parts (WHEN, THEN) can be written on one line or can be structured in several lines. Now, let’s consider a simple feature and discover how to create a simple model.

FIRST EXAMPLE

We describe here a feature by requirements, numbered R1, R2 and so on.

Firstly, read the requirements very carefully. You will never create a good model if you do not understand the requirements. Then try to extract the categories and the choices. They are in the text, but finding them needs some experience. After some modelling exercises, we can extract them easily. For example, read R1: ‘For online new book purchasing’. Here online is not important, because there is no alternative way of purchasing. However, we will recognise this when we learn the whole feature.

On the other hand, new book is relevant, since there are second-hand books on sale as well. Therefore, we can introduce a category book type with choices new book and second-hand book. Note that in this case, the book type is indirectly involved in the feature, and we can create it by recognising the two choices. Finally, purchasing is an action; however, the feature is only for price reduction, where actual buying does not happen. Thus, we can ignore it.

Reading R1 further, ‘regular customers with cards’ is a choice but we rename it. The category can be ‘card owner’ and the related choices are ‘yes’ and ‘no’. Price reduction is an obvious category with choices: 10%, 15% and no reduction. Since we know the whole specification, we can see that besides 10% the price reduction can be 15% and no reduction.

Considering R2 we can see that the new books have prices. Therefore, we have a new category, new book price. Determining its choices here BVA can help, since we have to test the ON point of the boundary, which is EUR 50; an OFF point, which is EUR 49.99; and an IN point, for example, EUR 1000.

Considering R3 we can find a new rule for a price reduction. Here is an open boundary, that is EUR 50 is an OFF point. This seems to be a little bit strange if the price boundaries for card owners and for the others are different. Here defect prevention works since the correct sentence is: If somebody has a card and buys new books for at least EUR 50, then the price reduction is 15 per cent.

In R4 we have ‘second-hand book’, and we have to validate that for second-hand books no price reduction happens. Therefore, we set prices for second-hand books as well. In this way, we have a category second-hand book price, with choices 0 and 100. We select a value significantly larger than 50 in case a developer forgets the distinction between new and second-hand books.

Finally, in R5, we have to validate the book’s price, which is calculated based on the original prices and reductions. This is an output category, and thus, the choices are the functions of the input values. However, it is not necessary to determine these choices in this phase. In some cases, it is better to postpone it until the creation of AC.

So, we have the following categories and choices (we modified the names when needed):

We extended the categories with (I) means input and (O) means output. A very important extension of choices is (D) means default, (S) means single. We explain the last two extensions below.

Now let’s create the AC. This is relatively simple. The first is a condition: when the card owner is ‘yes’, then the price reduction for new books is 10 per cent. Also, the new book price has to be less than EUR 50. Otherwise, the reduction would be 15 per cent. And that’s why (D) and (S) have been introduced. During test case generation, the generator selects a choice for each input category. However, choices with (D) will always be selected, while choices with (S) are selected only once for the categories missing in some AC. The only exception is that each choice has to be selected at least once. Thus, the acceptance criterion is as follows.

Card owner:
WHEN card owner IS yes
THEN price reduction for new books IS 10%
AND total price IS 44.99

The total price is implicitly set as 44.99 as the new book price 49.99 has an extension (D), and the second-hand book price is 0 because the test case generator selects the choices without (S). You can observe that each acceptance criterion may have a name such as Card owner. This will be the related generated test case name as well. Now we can easily create the three missing AC:

Expensive:
WHEN new book price IS 50
THEN price reduction for new books IS 10%
AND total price IS 45

Both:
WHEN card owner IS yes
AND new book price IS 50
THEN price reduction for new books IS 15%
AND total price IS 42.5

No reduction:
WHEN new book price IS 49.99
AND second hand book price IS 1
THEN price reduction for new books IS no reduction
AND total price IS 50.99

Note that second-hand book price is 1 in order to test the possibility of a bug when price reduction for new books is enabled based on the total price instead of the new book price.

When we create an acceptance criterion to test the case when second-hand books have no price reduction, the other choices have to be selected, forcing price reduction for new books. Here we also test the IN point (EUR 1000):

No reduction for second-hand books:
WHEN second-hand book price IS 100
AND card owner IS yes
AND new book price IS 1000
THEN price reduction for new books IS 15%
AND total price IS 950

We can also see that a 15 per cent price reduction for the new book is covered twice. Therefore, we can delete acceptance criterion Both. You may observe that we apply multiple fault assumption. Yes, in this case, the failure detection capability of this test is significantly higher than a test case where the buyer has no card and buys no new books at all. If the test fails, we can add the deleted acceptance criterion Both to help the developer discover whether price reduction for new or used books is faulty.

We are almost ready, but we can observe that the first category and the related choices remain unused. They are superfluous and can be removed. Modelling is an iterative work; after creating AC we may modify or delete some categories and/or choices.

Finally, we shall fill the output choices for total price:

total price (O): 44.99; 45; 50.99; 950

The tool generates the test cases just in time. In Figure 12.1 you can see the model of price reduction. The generated tests are on the bottom of the window. In the figure the AC are not formatted for space utilisation.

You can observe that the test cases have been generated without setting any test selection criteria. The test selection criteria in Harmony are as follows:

Here, the four AC have been converted to four test cases.

Finally, the manually executable test cases are generated (see Table 12.1), where the detailed test cases are shown. The input and the output are distinguished by different colours in the tool, here bold and roman. After executing the test case and filling the result with passed or failed as happened, the results are summarised (see Table 12.2). Note that we executed three test cases out of the four, two passed and one has failed.

Note that the new version of Harmony is capable of generating test code and executing it. This new functionality is outside the scope of our book, however, you can try it freely.

THE MODELLING LANGUAGE

We have seen the basic elements of the Gherkin-based modelling language, and we have made a simple model. However, complex systems are modelled in practice applying various important test design techniques. Therefore, we summarise the syntax of the modelling language and then show you how to use it for some of our previous examples.

GIVEN, WHEN, THEN, AND, IS

These are the basic keywords in the Gherkin and Gherkin++. GIVEN is used for preconditions where we would like to test a feature, and we have to cover an execution path for the feature to be tested. An example is: GIVEN Login is successful THEN… GIVEN is optional.

Figure 12.1 The model of price reduction

Table 12.1 Manual test cases for ‘Price reduction’

The syntax requires using both WHEN and THEN in all the AC. In contrast to the original Gherkin syntax, any WHEN-THEN-WHEN-THEN sequence is possible. In the following model a faulty pin code is entered twice, but the correct one is entered the third time.

WHEN Pin IS wrong THEN Message IS ‘wrong Pin code has been entered’
WHEN Pin IS wrong THEN Message IS ‘wrong Pin code has been entered’
WHEN Pin IS good THEN Message IS ‘Pin code is OK’

AND can be used to connect two (or more) GIVEN/WHEN/THEN statements.

IS/ARE connects a category and a choice of this category, such as MyCat IS MyChoice.

Table 12.2 Test results for ‘Price reduction’

Multi-layer structure

In general, the structure of software systems is complex and can mostly be arranged in hierarchical ways. Models have to express this multi-level structure as well. Harmony supports a multi-layered structure. Test cases from lower-level models can be used in higher-level models. There are two possibilities to utilise available test cases from other features:

1. (F) is a category type where the category name is an existing (lower-level) feature. The choices of this category can be the test case/AC names. The number of the layers is not limited. In this way, very complex test cases can be generated based on relatively simple models.

2. We can use available features and their test cases in another feature without any declaration. Therefore, we can delete ‘Login (F): successful; faulty (S)’. from CATEGORIES. Just type the feature name, and the selected test case name and Harmony will validate it.

Tables

Tables reduce the number of AC if they differ only with respect to the choices. For example, if there are two similar AC:

Twenty: WHEN original price IS 20 AND reduction is 10 THEN total price IS 18
One hundred: WHEN original price IS 100 AND reduction is 12 THEN total price IS 88

In this case, we substitute these two AC by one as follows.

MyTable: WHEN original price   IS 20 | 100
                AND reduction           IS 10 | 12
               THEN total price         IS 18 | 88

The name of the generated test cases will be MyTable[20] and MyTable[100] and can be called from other models by applying this name.

If you are a test analyst, you will understand this acceptance criterion and your model will be shorter. The generated test cases will also remain understandable for everybody.

If some category is missing from the acceptance criterion, then the choices are selected according to the category declaration, and the generator will iterate them.

You can see that the ‘payment method’ is missing from the acceptance criterion in the example. In this case the choices are selected one-by-one repetitively.

Sub-AC

A sub-acceptance criterion is an acceptance criterion that can be used in other AC. This is similar to functions in programming. In this way, common parts of AC can be extracted and used to shorten the AC. An example is below.

Replication (GO/GOES)

GO/GOES makes it possible to model state transition diagrams. Let’s assume a (transition, state) pair, for example, inserting an amount to be paid (a transition), and the remaining amount after this insertion (state). We can insert a series of amounts resulting in a series of remaining amounts. We can use WHEN-THEN-WHEN-THEN, but we simplify it by GO. Firstly consider the following acceptance criterion:

WHEN In IS 3 THEN Out IS yes
WHEN In IS 1 THEN Out IS no
WHEN In IS 2 THEN Out IS N/A

However, it is too verbose; fortunately, GO/GOES helps. The above acceptance crtierion can be transformed into:

WHEN In GOES 3; 1; 2 THEN Out GOES yes; no; N/A

Here for In = 3, Out = yes; for In = 1, Out = no; for In = 2, Out = N/A. It’s pretty simple, isn’t it?

TEST DESIGN MAINTENANCE

Until now we have not considered the question of maintaining test cases. As the specification and the code change, so do the test cases. Some of them become obsolete and some new test cases are required. We know that maintenance cost is the largest part of the project life cycle cost. Therefore test case maintenance is a critical issue. Fortunately, MBT can make test case maintenance cheaper. When the specification is changed the related model should also be modified. Based on the modified model, the test cases are generated again. Thus, no manual test case modification happens.

Also, maintaining the models instead of the test cases is a huge advantage. There is no need to generate all the test cases again; it is enough to generate only those affected by the modification. If the output is some new or modified executable test cases, then after the modification these test cases are automatically executed. More information about this can be found in Németh (2015).

For manual test execution, selecting the affected test cases is even more important. Assume that the tester has executed half of the test cases when a modification in the specification happens. They have to know what the new or the modified test cases are, otherwise very costly full re-execution is needed. By selecting and marking the affected test cases, the tester executes only some test cases. The result is not only a better code, but the team has continuous knowledge of the quality of the product.

Let’s consider an example for test case maintenance. Consider our previous ‘Price reduction’ example. Let’s modify the price reduction value from 15 per cent to 13 per cent. We select the original Microsoft Excel sheet as it contains the manual test results. Selecting ’EXPORT TEST FROM PREVIOUS RESULTS’ we get the results shown in Table 12.3.

We can see that only one test case has been modified – ‘No reduction for second-hand books’ where the price reduction was modified to 13 per cent. The result of the test execution for all the other test cases remained ‘passed’, ‘failed’ and empty, as this test case is unexecuted. Only the empty and the modified test cases will be executed and re-executed, respectively. We have a test case ‘no reduction’ with no result as it has not been executed. There are several causes for a test case being unexecuted; for example, the related code was not ready, or the tester just ran out of time.

Table 12.3 Test results for ‘Price reduction’ after feature modification

TICKET VENDING MACHINE EXAMPLE

We selected the user stories from Chapter 5 and Chapter 6 to show you how two test design techniques can be used in combination and how to model them. We extended these two with the successful transaction.

Remember that we designed seven test cases for RAP (remaining amount to be paid) (see Chapter 5). We modified T1 and T3, see Table 12.4.

The state transition graph includes the payment process, and the successful transaction is shown in Figure 12.2.

The BVA tests are inserted into S5: Payment normal mode, as you insert banknotes and coins until payment is successful. We model these three (Ticket selection, Buying process – S5 and Transition OK – S6) with different features. The basic feature is ticket selection, which will call the other features.

Table 12.4 Modified test cases for RAP

Figure 12.2 State transition graph for the TVM

Feature: Buying process

Now let’s consider the buying process. Tables are easily constructed in Harmony. The inputs are the inserted amounts; the outputs are the acceptable banknotes and the remaining amounts. Note that ticket prices are not inputs here. These are the output of the ticket selection process, and we will connect these two in the models. However, for clarity, we insert ticket prices as comments. The categories and the related choices are the following.

//Ticket price(I): 2.1; 7; 5.6; 10.5; 15.2; 21; 21

Inserted amount(I): 1; 5, 0.1; 2; 2.0; 0.5; 0.5, 0.2, 0.2; 0.50
Remaining amount(O): 0.1; 5; 5.1; 10; 10.1; 20; 20.1
Acceptable maximum banknote(O): 5; 10; 20; 50

If we insert more coins, we create a related choice such as 0.5, 0.2, 0.2; meaning we insert these three coins one by one. Making identical choices such as 0.5 and 0.50 is intentional, making the test case more understandable (for example BanknoteTest [0.50] instead of BanknoteTest [4]).

We have only one acceptance criterion from which the tool generates the seven necessary test cases:

Feature: insertMoney

BanknoteTest:
WHEN Inserted amount IS 2 | 2.0 | 0.5 | 0.50 | 5, 0.1 | 1 | 0.5, 0.2, 0.2
THEN Remaining amount IS 0.1 | 5 | 5.1 | 10 | 10.1 | 20 | 20.1
AND Acceptable maximum banknote IS 5 | 5 | 10 | 10 | 20 | 20 | 50

We obtain eight test cases:

BanknoteTest [2]: Inserted amount(I) =2, Remaining amount(O) =0.1, Acceptable maximum banknote(O) =5

BanknoteTest [2.0]: Inserted amount(I) =2.0, Remaining amount(O) =5, Acceptable maximum banknote(O) =5

BanknoteTest [0.5]: Inserted amount(I) =0.5, Remaining amount(O) =5.1, Acceptable maximum banknote(O) =10

BanknoteTest [0.50]: Inserted amount(I) =0.50, Remaining amount(O) =10, Acceptable maximum banknote(O) =10

BanknoteTest [5, 0.1]: Inserted amount(I) =5, 0.1, Remaining amount(O) =10.1, Acceptable maximum banknote(O) =20

BanknoteTest [1]: Inserted amount(I) =1, Remaining amount(O) =20, Acceptable maximum banknote(O) =20

BanknoteTest [0.5, 0.2, 0.2]: Inserted amount(I) =0.5, 0.2, 0.2, Remaining amount(O) =20.1, Acceptable maximum banknote(O) =50

These are the necessary boundary value test cases.

Feature: Transaction OK

Inserting the remaining coins and/or banknotes for successful payment is very similar.

Categories and choices:

Inserted amount(I): 0.1; 5; 5, 0.1; 10; 10, 0.1; 20; 20, 0.1;
Remaining amount(O): 0(D)
Number of tickets printed(O): 1; 4; 5; 2; 10
Action(O): initial screen(D)

AC:

Print:
WHEN Inserted amount IS 0.1 | 5 | 5, 0.1| 10 | 10, 0.1 | 20 | 20, 0.1

THEN Number of tickets printed IS 1 | 5 | 4 | 5 | 2 | 10 | 10
Harmonygenerates the test cases below:

Print [0.1]:
Inserted amount(I) =0.1, Remaining amount(O) =0, Number of tickets printed(O) =1, Action(O) =initial screen

Print [5]:
Inserted amount(I) =5, Remaining amount(O) =0, Number of tickets printed(O) =5, Action(O) =initial screen

Print [5, 0.1]:
Inserted amount(I) =5, 0.1, Remaining amount(O) =0, Number of tickets printed(O) =4, Action(O) =initial screen

Print [10]:
Inserted amount(I) =10, Remaining amount(O) =0, Number of tickets printed(O) =5, Action(O) =initial screen

Print [10, 0.1]:
Inserted amount(I) =10, 0.1, Remaining amount(O) =0, Number of tickets printed(O) =2, Action(O) =initial screen

Print [20]:
Inserted amount(I) =20, Remaining amount(O) =0, Number of tickets printed(O) =10, Action(O) =initial screen

Print [20, 0.1]:
Inserted amount(I) =20, 0.1, Remaining amount(O) =0, Number of tickets printed(O) =10, Action(O) =initial screen

Feature: Ticket selection

In this feature we connect the three parts of the TVM process: (1) ticket selection, (2) inserting less money than expected, (3) inserting the remaining money, (virtually) printing the ticket and going back to the welcome (initial) screen. Here we consider the ticket selection and then call the test cases from the other two features. Remember from Chapter 6 that we have three complex and three simple test paths to cover the all-transition-state criterion.

The ticket selection model has only one input category: TVM transition

TVM transition(I): increase St first; increase St; decrease St to 0; decrease St 9X; increase 24 first; increase 24; decrease 24 to 0; decrease 24 9X; increase short first; increase short; decrease short to 0; decrease short 9X; increase St 9X; increase short 9X; increase 24 9X; increase short 4X; increase St 4X

Where, for example, increase St 9X means traversing t7 incStan in Figure 12.2 nine times. We have four outputs as we have the number of tickets for the three ticket types and one output for price:

Number of St tickets(O): 0; 1; 10; 5
Number of Short tickets (O): 0; 1; 10; 4; 5
Number of 24 tickets(O): 0; 1; 2; 10;
price(O):1.4; 2.1; 7.6; 5.6; 7; 10.5; 15.2; 21

The three complex paths described in Chapter 6, have been extended according to additional elements in the graph. We use the same abbreviations (Init, St, Short, 24, Payment and Success) for states, and insert for insertMoney and enough for insertEnough Money for the transitions. We also use (10X) for repeating the transition 10 times.

Tpath1 = Init – incStan – St – incStan(10X) – St – decStan(11X) – Init – incStan – St – decStan – Init – incShort – Short – decShort – Init – inc24 – 24 – selectPay – Payment – insert – Payment – enough – Success

Tpath2 = Init – incShort – Short – incShort(10X) – Short – decShort(11X) – Init – incShort – Short – decShort – Init – inc24 – 24 – dec24 – Init – incStan – St – selectPay – Payment – insert – Payment – enough – Success

Tpath3 = Init – inc24 – 24 – inc24(10X) – 24 – dec24(11X) – Init – inc24 – 24 – dec24 – Init – incStan – St – decSt – Init – incShort – Short – selectPay – Payment – insert – Payment – enough – Success

You can see that pairs (insert/enough, Init/St/Short/24/Payment) are not covered. We execute these test cases together as one large test case, and in this way the test selection criterion is satisfied.

Note that we make sub-AC according to these test paths involving the underlined sub-path. You can see that we separate decreasing ticket number into three parts: (1) 9 times to reach 1, (2) decrease to 0, (3) try to decrease below 0. The case for ticket increase is similar. Here is the sub-acceptance criterion for the standard tickets:

First St Steps:
WHEN TVM transition GOES increase St first; increase St 9X; increase St; decrease St 9X; decrease St to 0; decrease St to 0; increase St; decrease St to 0
THEN Number of St tickets GOES 1; 10; 10; 1; 0; 0; 1; 0 AND Number of Short tickets IS 0 AND Number of 24 tickets IS 0
WHEN TVM transition GOES increase short first; decrease short to 0
THEN Number of Short tickets GOES 1; 0

Sub-acceptance criterion First St Steps is used for acceptance criterion Test St and 10.1 below, where T5 is modeled involving the following steps:

Here is the acceptance criterion:

Test St and 10.1:
WHEN First St Steps
WHEN TVM transition IS increase 24 first
WHEN TVM transition IS increase 24
THEN Number of 24 tickets IS 2
AND price IS 15.2
WHEN Buying process IS BanknoteTest [5, 0.1]
WHEN Transaction OK IS Print [10, 0.1]

Here we connect the three features by calling Buying process and Transaction OK in Ticket selection.

From this acceptance criterion Harmony generates a complex test case with almost 50 test steps.

To cover the six test cases based on STT and the seven test cases based on BVA we need eight test cases altogether. We cannot cover both test selection criteria with seven test cases.

Besides the three complex test cases representing Tpath1-first-try, Tpath2-first-try and Tpath3-first-try, we have five simpler ones. Here we use very short sub-AC such as:

First St:
WHEN TVM transition IS increase St first
THEN Number of St tickets IS 1 AND price IS 2.1

Here is the model of T7 (see Table 12.4):

Test 20.1:

GIVEN First St
WHEN TVM transition IS increase St 9X
THEN Number of St tickets IS 10 AND price IS 21
WHEN Buying process IS BanknoteTest [0.5, 0.2, 0.2]
WHEN Transaction OK IS Print [20, 0.1]

The generated test shows what happens:

Test 20.1:

First St {TVM transition(I) =increase St first }, TVM transition(I) = increase St 9X, Number of St tickets(O) =10, price(O) =21,

Buying process(F) =BanknoteTest [0.5, 0.2, 0.2] {Inserted amount(I) = 0.5, 0.2, 0.2, Remaining amount(O) =20.1, Acceptable maximum banknote(O) =50 },

Transaction OK(F) =Print [20, 0.1] {Inserted amount(I) = 20, 0.1, Remaining amount(O) =0, Number of tickets printed(O) =10 }

Finally, we connect the execution of the three complex test cases resulting in one even more complex test case:

Complex:
WHEN Test 24 and 5
WHEN Test St and 10.1
WHEN Test Short and 10

We can see that for simple features (when EP and BVA only can be applied) modelling is simple. This is also the case for pure STT test design. However, when multiple test design techniques are used in combination or there are several model layers, the modeller’s task is more difficult. Fortunately, in most of the cases, we can separate the models related to the different test design techniques, and after that, we can connect them. In Appendix A of this book, you can study the whole model of this specification.

METHOD EVALUATION

Here we only evaluate the free tool Harmony and do not consider its test execution automation capability.

Applicability

The modelling method supports automated test design for testers and developers. It can be applied to projects where the specification can be divided into manageable parts. It can be used mainly for specifications, which can be tested by EP and BVA, STT and combinative testing. It can even be used for distributive and probabilistic systems.

Advantages and shortcomings of the tool

The main advantages are:

The shortcomings are:

THEORETICAL BACKGROUND

The starting point of Harmony is the category-partition method, for specifying and generating functional test cases (Ostrand and Balcer, 1988). Category-partitioning is a

method for creating functional test suites which has been developed in which a test engineer analyzes the system specification, writes a series of formal test specifications, and then uses a generator tool to produce test descriptions from which test scripts are written.

(Ostrand and Balcer, 1988, p. 676)

The first four steps of the method are similar to Harmony’s modelling:

The remaining steps are as follows:

One of the main differences between the category-partition and Harmony is that that the former generates test cases in combination, then the tester tries to reduce the number of test cases. The latter generates a linear number of test cases with respect to choices.

The other element of Harmony is the Gherkin language, which was originally used in Cucumber (Wynne and Hellesøy, 2012). Each line starts with a Gherkin keyword, which can be:

Now Gherkin is used in many testing tools, making test cases more understandable.

KEY TAKEAWAYS

EXERCISES

E12.1 Consider the feature presented in E6.2. Create the extended Gherkin model for this feature by applying all-transition-state criterion.

E12.2 Consider E5.1 ‘Payment’. Create the extended Gherkin model of this specification.