Test Design — Readability versus Writeability

Test Design Risks for Both Manual and Automated Testing

The growing interest in test automation is offset by the concern about risk. One of these risks is inadequate test design that can’t be used as the background for automated test scripts development and execution. Keep in mind, however, that the risk of inadequate testing design is a problem with testing as a whole (outside the scope of test automation).

High quality test design can simplify and speed up the process of the:

  • Manual tester (Test execution)

Test Design and Requirements

Let’s go over some test design basics. Testing is always performed against requirements which are required to be:

To double-check them all it’s necessary to start test design activities as soon as possible. Requirements are typically changed during project performance. These changes are to be reflected in the test design and test scripts.

Data-driven testing is based on the separation of test steps and test data, allowing for two things:

  • Increasing the number of test data (typical action in test automation) without a test script update

What is a Test Case?

A test case consists of format and content. The basic format is the same everywhere:

The Devil is in the Details

The main question is “Is the context adequate to the format?”.

Consider the typical test case (Fig. 1):

The questions for this test case are:

  • What do the terms “few,” “any,” or “for example” mean?

Note that these questions appear in both manual and automated testing.

What is the (Updated) Test Case?

We can modify the test case structure to be the following:

  • Step # (No changes)

So we get a better test case result (Fig. 2):

Fig. 2 A better test case

Repetitions and Wording

Some of the aforementioned issues are now resolved, but steps remain. The next steps are to get rid of the following:

  • Constructions like “Repeat steps from … to …” that may cause confusion during manual testing and make the automated test script more complicated and difficult to update (do not forget about requirements changes)

Fig. 3 Sample of the use of “corresponding” within the text

Feel the Difference Between Actions and Expected Results

The next activity is to separate mixed actions and expected results (Fig. 4).

The rules are:

  • All actions (for example, step 12) are placed in the “Action” column.

This reduces the number of test case steps.

“Le Mieux Est L’ennemi du Bien,” or BIEGE (The Best Is the Enemy of the Good Enough)

The next step is to get rid of universal scripts where UI depends on the test data (Fig. 5):

Figure 6 shows another example of universal scripts:

Fig. 6 One more example of universal scripts

There is a universal “Execute action” command on test case step 5 that is executed as “Move 1 element …” for data set GU-01 and as “Move all elements …” for data set GU-02. Nevertheless, it means a mix of test case steps and test data that leads to more complicated manually-tested actions and automated test script code. In this case it may be better to develop more test cases that will be simpler and easier to understand, automate and maintain.

What Test Case is Recommended in Data-Driven Testing?

Test Case Format:

  • Step #

Test Case Content:

  • No explicit cycles — use several data sets instead of

Data Set:

  • Roles, values

Data Preparation:

  • Preconditions (database content)

How to Know if You’re On the Right Path


  • There is a reasonable balance between test case step complexity and test dada complexity

The pluses are:

  • Manual testing — An increase of test execution reliability

Interested in upgrading your skills? Check out our software testing trainings.

Originally published at https://www.luxoft-training.com.