Data Combination Test

Coverage types

Description

The data combination test ( DCoT) is a versatile technique for the testing of functionality both at detail level and at overall system level. In the embedded world, this technique is also known as the “Classification Tree Method”. It was developed by Grochtmann and Grimm.

For the DCoT, no specific test basis is required. All types of information on the functionality of the system are usable:

Formal system documentation, such as functional design, logical data model and requirements
Informal documentation, such as manuals, folders, pre-surveys and memos
Domain expertise that is not documented, but resides ‘in the experts’ heads’.

The fact that domain expertise is usable as a test basis also makes this technique suitable for situations in which specifications are incomplete or out of date, or even unavailable altogether.

With the DCoT, the test situations are determined by reasoning from within the data attribute as to which variations should be tested. The basic technique used here:

Equivalence classes

Depending on the agreed test intensity, the coverage can be extended by fully combining the equivalence classes of two or more different data. In this,

For this coverage type data combinations is used:

  • One or more “data pairs” (testing of the most interesting pairs of data indicated by the experts, e.g. on the basis of risk assessment)
  • Pairwise testing
  • N-wise testing (extension on Pairwise)
  • All possible combinations (= multiple condition coverage applied on data, instead of conditions)

Pairwise testing
Complete decision table (multiple condition coverage) on selected data attributes.

Besides these, there is the option of reinforcing the test by applying boundary value analysis. This can also be applied selectively, by defining the boundary values for specific data attributes as a separate equivalence class.

Thanks to its versatility, the data combination test is suitable both for testing those functions that are deemed very important, and for testing system parts that ‘just need a quick test’.

Points of focus in the five general steps

1. Identifying test situations

Identifying test situations is the creative step in the process and is ideally carried out by a team in which various forms of expertise are represented.

During this step, the following activities are carried out:

  • Determine the data attributes that influence the functionality. This does not automatically mean all the data attributes that are used by the function. It concerns the data attributes that are of influence on variations in the system behaviour. This includes the data attributes for which equivalence classes can be determined. The defined data can consist of entities, attributes or functional concepts in a general sense.
  • Determine the equivalence classes for each data attribute
  • Determine the relationships between the data attributes. Some data attributes are only of influence on the system behaviour under certain conditions, namely if another data attribute has a value from a specific equivalence class. That means that the possible variations of the first-mentioned data attribute must be combined with the specific value of the last-mentioned data attribute. In the example set out, such a relationship is visible between the data attributes “search criterion” and “flies to that destination”.

The result can be illustrated in a ‘classification tree’:

  • Data attributes that logically belong together can be grouped under an overall title, such as “personal details” or “employer types”
  • Under every data attribute the equivalence classes are hung, like branches on the tree
  • Relationships between the data can be shown simply by hanging the relevant parts of the classification tree directly under the relevant equivalence class.

The creation of the classification tree with which the test situations are identified is an iterative and interactive process, in which the parties involved inspire, correct and complement each other. How far this process will go is the choice and responsibility of the team. A test manager who wishes to keep this well under control will provide a concrete job description for the team and request regular feedback on the results.

If required, it is defined which data attributes are eligible for ‘fully combined testing’. That means that all the possible combinations of all the equivalence classes of those data attributes should be tested. How many of such combinations can be defined depends on the agreed depth of testing.

2. Creating logical test cases

With a logical test case, precisely one of the equivalence classes is covered for each data attribute in the classification tree. Collectively, the logical test cases should at any rate cover all the equivalence classes of all the data attributes. Depending on the chosen depth of testing, they should also cover all the combinations of equivalence classes of particular data attributes, if necessary.

In principle, there are two ways of demonstrating this clearly:

  • In table form. This method is usually employed where the “pairwise testing” option has been adopted. Tools for pairwise testing normally deliver their results directly in table form.
  • Graphic depiction of a ‘classification tree’. This is particularly useful if the most elementary form of testing (without combinations) has been chosen, or for the selective application of “complete decision table” coverage. Ideally, a graphic tool should be used here. The tool “Testona” can be downloaded via the Internet (http://www.berner-mattner.com/de/produkte/testona/index.html).

3. Creating physical test cases

In creating the physical test cases, concrete values should be chosen for all the input data. These input data do not always correspond exactly with the concepts maintained in the classification tree. For example, the classification tree may contain the concept of “duration”, while the function to be tested expects the data “Start date” and “End date”.

Every physical test case should have a concrete predicted result. However, this generally depends on the other data and system settings that belong with the chosen starting point.

In order to predict the results of every physical test case, it is necessary to know exactly which flights and prices are stored in the database. This step goes hand-in hand with the next step, “Establishing the starting point”.

4. Establishing the starting point

This step is identical to the general case of a test design technique.

5. Creating the test script

This step is identical to the general case of a test design technique.