Test design techniques

Test design can be as simple as hitting some keys unprepared to see if a system works at all (called ad hoc testing). And it can be as sophisticated as identifying test situations, assuring coverage by designing test cases, automating these in a test script and executing the script to automatically create a test report. Both unstructured testing and structured testing can be used as a quality measure. To determine which approach is preferred very much depends on the situation (especially the quality risks involved). For the preparation and performance of tests, we distinguish two overall approaches:

• Coverage-based testing
• Experience-based testing

In both approaches we can identify higher and lower degrees of structured work, although basically the coverage-based approach will be more structured than the experience-based approaches. However, more structure doesn't necessarily mean it better contributes to establishing confidence in the pursued value. It is always wise to combine both approaches; sometimes more experience-based, sometimes more coverage-based, but never exclusively one or the other.

For a more in-depth explanation: read more.

Introduction

Why test design techniques?

The aim of testing is to provide advice on quality and risks. To do this, the tester needs to collect information about the system behaviour. The most important means to achieve this is to execute test cases. The big questions in this context are: 'Which test cases? How many? And how do we get these test cases?' Test design techniques play an important part in answering these questions.

Designing test cases is the vital link between the test strategy and the concrete test cases that are used to implement that test strategy. This is realised in the context of test assignment to test cases, the theme of which can be outlined as follows:

• It is not possible to test everything within the confines of the preconditions of time and costs defined in the job specification. Choices will have to be made as to the lengths one wishes to go to in testing.
• The more important something is, the more intensive the tests required. Something is very important if its failure would result in severe damage to the business or client. This is mapped by means of a risk analysis.
• A test strategy is used to create an overview of what will be tested and how intensively, such that the risks defined earlier are covered as adequately as possible.
• The decisions concerning intensive and less intensive testing are translated to concrete statements about the targeted coverage.
• Depending on the available test basis, among other things, appropriate test design techniques are selected to achieve said coverage.
• The implementation of these techniques eventually results in the set of test cases that is needed to execute the test assignment satisfactorily.

Importance of test design techniques

You will find several arguments below that indicate the importance and benefits of using test design techniques and their definition in the test specifications.

• It provides a justified elaboration of the test strategy: the agreed coverage in the agreed place
• Because a test design technique focuses on achieving a specific coverage to detect specific types of defect (e.g. in the interfaces, the input checks or the processing), such defects are detected more effectively then by specifying ad hoc test cases
• The tests are reproducible because the order and content of the test execution are described in detail
• The standardised method ensures that the test process is independent of the individual who specifies and executes the test cases
• The standardised method ensures that the test specifications are transferable and maintainable
• It becomes easier to plan and manage the test process because the processes of test specification and execution can be split up into clearly definable blocks.

Essential test design concepts

Test situation, test case and test script

In the ideal case, testing would give us the certainty that the system behaved as required or desired under all circumstances. In reality, not every circumstance can be tested – only a subset that is a direct result of the decisions and choices made during the test design phase. The test design leads to a hierarchical structure of test situations – test cases – test scripts. These terms are discussed in detail further on in this section. The relationship between the concepts can be summarised as follows:

• Every test situation occurs in at least 1 test case.
• A logical test case covers 1 or more test situations.
• Every logical test case is worked out concretely into 1 physical test case .
• Every physical test case occurs in 1 test script.

The distinction between the logical and physical parts of the test design is:

• The logical test design consists of the test situations and the logical test cases. This is the part that demonstrates that the required coverage is achieved, thereby complying with the test strategy.
• The physical test design consists of the concretely created physical test cases, laid down in test scripts. This guarantees a thorough preparation of the 'Execution' phase. The physical creation of test cases therefore adds nothing to the thoroughness of the test.

For a more in-depth explanation: read more.

Overview of the test design techniques

The table below summarises the most important features of the test design techniques discussed here. This can be of assistance in comparing the techniques and in selecting the most suitable ones.

Another view: Selection of Coverage types and Test design techniques

There exist many coverage types and test design techniques. For the sake of simplicity and practicality we will only highlight the most commonly used test design techniques and hence the application of the underlying coverage types.

To give you a practical overview we highlight the most commonly used coverage types and some test design techniques in which they can be applied.

We left out the coverage group "Appearance". In the cases where that coverage group is applicable, the coverage type and thourougness depends too much on the specific interface and the result the tester wants to achieve.