Businesses in general, and IT businesses in particular, have always aimed to increase efficiency through process automation. This includes automating application testing. Rather than running the application manually and executing the same additional test steps again and again, using the appropriate tools or scripts can now make this happen automatically.
The goal is clear – but how to get there? As is often the case, many paths are open but not all are equally up to the task. One obvious option is to translate the test cases used before into a script, creating an exact replica. But, better solutions are available. Businesses should recognise the opportunity inherent in switching from manual to automated testing: that is, to improve the structure of test cases and the manner in which tests are developed. One approach in particular stands out: key-word driven testing.
If you compare all possible test cases for any given application you will usually find that many cases contain the same test steps. This is the starting point for key-word driven testing. The basic idea is to build test cases out of individual, indivisible test steps – the so-called key words. The same test step, i.e., the same key word, appears in many test cases and only needs to be implemented once. Once it has been implemented, it can be used again and again. Key-word driven testing is characterised by the creation of a repertoire of key words, which in turn forms the basis of all test cases.
And what are the advantages of key-word driven testing?
- The first advantage is a reduction in the time needed to create new test cases. Once the repertoire of key words reaches a certain size, new test cases can be built entirely, or almost entirely, from existing key words. This substantially reduces the effort needed to implement new cases.
- And if you go through the effort of building a series of test cases you are likely going to want to use them over a long period of time. Or, put differently, being able to maintain your cases is important. Obviously, if an application changes, the test cases must also change. But what if a change affects a hundred test cases? Does that mean that the scripts for a hundred test cases need manual updates? The answer for key-word driven testing is a clear “no”. Each key word is only implemented once and all test cases use that one implementation. So, only a change only requires adapatation of one implementation.
Key-word driven testing uses the same concept – modularisation – known to many from modular programming or microservice architecture. You can think of key words as functions, and just as is the case with functions, key words can be parametrised.
In closing, the following example illustrates how key words can be used, showing a typical step by step process. This example consists of the creation of GUI tests for an online shop.
- Application start: a client accesses the online shop
- Product choice: a client chooses a product
- Payment: a client chooses from possible payment options
- Closing the application: a client leaves the online shop
In the interest of simplicity, test steps will be presented at a high level. Each test step can be understood as a key word, which needs to be implemented as such. The choice of product, for instance, could look as follows:
productchoice(product, amount):
- Choose the product “product”
- Set amount to the value “amount”
- Put the chosen product into the cart
This key word can be used in other test cases without re-implementing any of the individual steps. For instance, another test case could check whether products can also be removed from the cart.
In addition, the product and the chosen amount have already been implemented as parameters. Without additional effort this offers the possibility of further test cases such as testing whether discounts effective above a certain amount of items work as intended.
This simple example illustrates the advantages of key-word driven testing, in particular when compared to the traditional linear testing familiar from manual tests. All you need to build a future proof and flexible test system is a small amount of prior analysis.
