Decision Table Test (DTT)

Description

The decision table test is a thorough technique for the testing of detail functionality. The required test basis contains conditions or decision tables. The type and structure of this test basis is of minor importance to the application of the decision table test technique.

This video explains this test design technique. Below the video more informatio and the explanation is available in text.

The decision table test is aimed at the thorough coverage of the conditions and not at combining functional paths. The basic technique used here is:

• Decision points: Multiple Condition coverage

Variations on the decision table test can be created by applying the basic technique:

• Decision points: Condition coverage, Decision coverage or Condition/Decision coverage.
  • With these, decision points can be tested in less depth
• Boundary value analysis
  • With this, the possibilities of a condition can be tested in more depth.

It is a preferred technique for the testing of functions and/or complex calculations considered to be very important.
 

Points of focus in the steps

In this section, the decision table test is explained step by step, taking the generic steps as a starting point (see “Introduction“). An example is also set out showing at every step how this technique works.

The test basis consists of decision tables, pseudo-code, a process description or other (functional) descriptions, in which conditions occur. The conditions and the results are put into a decision table. The general shape of a decision table after step 2 – “Creating logical test cases” is shown in the table below.

Identification table

Test situations	1	2	..	n
Condition 1	0	0	..	1
Condition 2	0	~	..	0
Condition ..	0	..	~	0
Condition n	0	1	..	0
Result 1	X	..	..	..
Result ..	..	..	..	..
Result n	..	..	..	..
Not possible	..	..	X	..

Each column of the decision table forms a test situation. The part above the double line forms the situation description and the part below the line reflects the consequences, or the results.

The conditions can have the values of “0” or “1” (see also “Decision Points“). The value “1” means that the condition is true; the value “0” means that the condition is false. The value “~” can also be allocated. This means that the value of the condition is not important. Below the double line, the cells contain an “X”, or are empty. Where there is an “X”, the relevant result occurs in that test situation; if a cell is empty, the relevant result does not occur in that test situation. Several results are possible per test situation. “Not possible” indicates that the test situation is not physically executable, for example because certain values of conditions exclude each other.

Example

When ordering coffee capsules via the Internet, the shipping costs are calculated. These consist of the standard shipping costs, plus a long-distance supplement. The text below shows the associated process description. Shipping costs calculation: Calculation of standard shipping costs If 200 or more capsules are ordered and if the form of payment is “direct debit”, then no shipping cost is applied. If fewer than 200 capsules are ordered, or if the form of payment is other than “direct debit”, then a shipping cost of €10 is applied. Calculation of long-distance supplement If the delivery address for the capsules is within a radius of 50 km of Utrecht, no long distance supplement is applied. If the delivery address is 50 km or more from Utrecht, but still in the Netherlands, then a long-distance supplement of €5 is applied. If the delivery address is outside of the Netherlands, then a long-distance supplement of €15 is applied. (The highest sum is applied.)

1 – Identifying test situations

Below, each step is set out showing how the decision table test is applied to this process:

To fill in the table, in step 1 “Identifying test situations” the following activities are carried out:

• Find conditions in the test basis
• Create a conditions list
• Find results in the test basis and add these to the conditions list
• Fill in the decision table.

The activities are explained below:
The finding of conditions involves a degree of detective work. Often, a condition in the test basis is preceded by words such as “if” and “then” and can be looked for by this means.

Example

The tester has identified the conditions in the process description. Shipping costs calculation: Calculation of standard shipping costs If 200 or more capsules are ordered andif the form of payment is “direct debit”, then no standard shipping costs are applied. If fewer than 200 capsules are ordered or if the form of payment is other than “direct debit”, then a standard shipping cost of €10 is applied. Calculation of long-distance supplement If the delivery address for the capsules is within a radius of 50 km from Utrecht, then no long-distance cost is applied. If the delivery address is 50 km or more from Utrecht, but still in the Netherlands, then a long-distance supplement of €5 is applied. If the delivery address is outside of the Netherlands, then a long-distance supplement of €15 is applied.

A condition is singular (therefore without “AND” or “OR” constructions)Subsequently, a conditions list is created. If the test basis is a decision table, the conditions can often be copied one for one. In creating the list, the following rules are applied. These rules are created in order to keep the decision tables clear and intelligible:

• A condition is formulated positively (in order to avoid “not not” combinations)
• Try to keep the number of conditions per table to five or lower (that is maximum 2⁵ = 32 test columns). If there are more conditions, split the table into several tables.
  

Example
Concerning the shipping costs calculation, the tester arrives at the following conditions list: Calculation of standard shipping costs C1 order ≥ 200 capsules C2 form of payment = “direct debit”Calculation of long-distance supplement C3 distance < 50 km from Utrecht C4 country = The Netherlands

When the conditions list is known, the results are added to it. The tracing of the results also involves some detective work. A result is often preceded in the test basis by words such as “then” and “else”.Creating a conditions list may require some interpretation of the description. There often appears to be more conditions necessary in order to reach a particular situation. In that case, investigate whether there is indeed a supplementary condition or if a particular situation can be realised by one or more of the recognised conditions being false.

Example

The tester has identified the results in the process description. Shipping costs calculation: Calculation of standard shipping costs If 200 or more capsules are ordered and if the form of payment is “direct debit”, then no standard shipping costs are applied. If fewer than 200 capsules are ordered or if the form of payment is other than “direct debit”, then a standard shipping cost of €10 is applied. Calculation of long-distance supplement If the delivery address for the capsules is within a radius of 50 km from Utrecht, then no long-distance supplement is applied. If the delivery address is 50 km or more from Utrecht, but still in the Netherlands, then a long-distance supplement of €5 is applied. If the delivery address is outside of the Netherlands, then a long-distance supplement of €15 is applied. The tester adds the results to the conditions list:Calculation of standard shipping costs: C1 Order ≥ 200 capsule C2 Form of payment = “Direct debit” R1 Standard shipping costs := 0 R2 Standard shipping costs := 10 Calculation of long-distance supplement C3 Distance < 50 km from Utrecht C4 Country = The Netherlands R3 Long-distance supplement := 0 R4 Long-distance supplement := 5 R5 Long-distance supplement := 15

Now that both conditions and results are known, the decision table is filled in in accordance with multiple condition coverage.

Example

Shipping costs calculation (test situations)
Std. shipping costs / Long-distance supplement	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16
C1 Order ≥ 200 capsules	0	0	0	0	0	0	0	0	1	1	1	1	1	1	1	1
C2 Form of payment = “direct debit”	0	0	0	0	1	1	1	1	1	1	1	1	0	0	0	0
C3 Distance < 50 km from Utrecht	0	0	1	1	1	1	0	0	0	0	1	1	1	1	0	0
C4 Country = The Netherlands	0	1	1	0	0	1	1	0	0	1	1	0	0	1	1	0
R1 Std. shipping costs := 0									X	X	X	X
R2 Std. shipping costs := 10	X	X	X	X	X	X	X	X					X	X	X	X
R3 Long-distance supplement :=0			X	X	X	X					X	X	X	X
R4 Long-distance supplement :=5		X					X			X					X
R5 Long-distance supplement :=15	X			X	X			X	X			X	X			X

Filling in a table with ones and zeros can be done in many ways. The manner of doing so in the above “Shipping costs calculation” table simplifies the creation of physical test cases (see “In more detail” below for explanation).

In more detail

Note the handy way of filling in the “Shipping costs calculation” decision table. This causes only one condition to change in value per column (referred to in the literature under the name of: “Gray-code”). This is helpful for the creation of the physical test cases: copy and paste and change one value. For the filling in, we begin at the bottom row of conditions with one 0 followed by, consecutively, two times 1, two times 0 and so on until the last, which is given the value 0. In the row second from the bottom, we begin with two times 0 followed by, consecutively, four times 1, four times 0, and so on until the last two, which are given the value 0. We continue like this with the whole table; in every row the zero and one sets are twice as long as in the previous row.

In more detail

Shipping costs calculation (test situations)
Std. shipping costs / long-distance supplement	1	2	11
C1 Order ≥ 200 capsules	0	0	1
C2 Form of payment = “direct debit”	0	0	1
C3 Distance < 50 km from Utrecht	0	0	1
C4 Country = The Netherlands	0	1	1
R1 St. shipping costs := 0			X
R2 St. Shipping cost := 10	X	X
R3 Long-distance supplement := 0			X
R4 Long-distance supplement := 5		X
R5 Long-distance supplement := 15	X

With the three columns, all the possible outcomes of each condition and of each result are covered at least once. The columns 1 and 11 cover all the conditions, and column 2 is necessary to cover result 4 as well.

Several combinations of columns are possible that meet with the condition/decision coverage (e.g. 3, 9, 10 and 2, 11, 16).

In more detail

Besides conditions that can only assume the values of true or false, parameters also exist with more than 2 possible values (i.e.: equivalence classes). There are two ways of dealing with these:

1. Split the parameters into several conditions that can only be true or false. The approach described in this section can then be used.
2. .Add as many columns as there are possible equivalence classes, whereby the content of the other rows of conditions does not change. Suppose that in the example there is a choice of three forms of payment: direct debit, giro transfer and cash. Then, as an example, the ‘old’ test situation 1 would lead to the following 3 ‘new’ test situations in this approach:
   

Std. shipping costs / long-distance supplement	1	2	3
C1 Order ≥ 200 capsules	0	0	0
C2 Form of payment	“direct debit”	“Giro tr.”	“Cash”
C3 Distance < 50 km from Utrecht	0	0	0
C4 Country = The Netherlands	0	0	0
R2 St. Shipping cost := 10	X	X	X
R5 Long-distance supplement := 15	X	X	X

For more information on this, refer to “N-wise testing” in “Orthogonal arrays and pairwise testing” and to books on theory, such as [Copeland, 2003].

2 – Creating logical test cases

The test situations (columns) in step 1 now constitute the logical test cases.
However, a logical test case must not contain ‘mutually exclusive conditions’, since that would make the test case inconsistent in itself, and therefore unexecutable. In the step from test situations to logical test cases, any unexecutable test cases should be traced. These test cases are marked “Not possible” in the table.

Example

In the shipping costs example, the conditions C3 and not-C4 exclude each other. There are no foreign locations within a radius of 50 km from Utrecht. Therefore, 4 of the 16 logical test cases are unexecutable, see table below:

Shipping costs calculation (logical test cases)
Std. shipping costs / long-distance supplement	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16
C1 Order ≥ 200 capsules	0	0	0	0	0	0	0	0	1	1	1	1	1	1	1	1
C2 Form of payment = “direct debit”	0	0	0	0	1	1	1	1	1	1	1	1	0	0	0	0
C3 Distance < 50 km from Utrecht	0	0	1	1	1	1	0	0	0	0	1	1	1	1	0	0
C4 Country = The Netherlands	0	1	1	0	0	1	1	0	0	1	1	0	0	1	1	0
R1 Std. shipping cost := 0									X	X	X
R2 St. Shipping cost := 10	X	X	X			X	X	X						X	X	X
R3 Long-distance supplement := 0			X			X					X			X
R4 Long-distance supplement := 5		X					X			X					X
R5 Long-distance supplement := 15	X							X	X							X
Not possible				X	X							X	X

Check for yourself that the logical test cases 4, 5, 12 and 13 are not executable.

For the logical test cases with the result of “Not possible”, no physical test case exists. Ideally, these columns should not be removed, so that no misunderstanding can arise as to why no physical test case is present for a particular logical test case.

3 – Creating physical test cases

With a physical test case, all the data that play a part in the conditions are translated into concrete terms. To this end, the table of logical test cases can simply be adapted for making the test cases physical. In the table of physical test cases, each numbered column describes a physical test case and the last row(s) contain(s) the predicted result(s). For the entries:

• The “0” or the “1” is replaced in the table with a physical value
• The physical value is entered in the place of an “X”.

A point of focus with the first bullet is that in the table of physical test cases, no conditions remain, only data. A particular data attribute can occur in several conditions. In logical test cases, they occur in several rows, while that particular data naturally only occurs once in the table for physical test cases. Besides this, it is possible that additional refinements are required. For example, by putting derived data into concrete terms (see example below).

Example

For the creation of physical test cases, the “Place of delivery” has to be derived from “Distance from Utrecht”. This delivers the table below (as an example, 8 of the 12 logical test cases are shown):

Shipping costs calculation (physical test cases)
	1	2	6	7	9	10	11	16
Number of capsules	199	199	199	199	200	200	200	200
Form of payment	cash	cash	dir.dbt.	dir.dbt.	dir.dbt.	dir.dbt.	dir.dbt.	cash
Distance from Utrecht	178	182	10	182	178	182	10	178
Place of delivery	Brussels	Heerlen	Zeist	Heerlen	Brussels	Heerlen	Zeist	Brussels
Country	Bel	Ned	Ned	Ned	Bel	Ned	Ned	Bel
St. shipping cost	10	10	10	10	0	0	0	10
Long-distance suppl.	15	5	0	5	15	5	0	15
Total shipping costs	25	15	10	15	15	5	0	25

The logical test cases 4, 5, 12 and 13 are not executable and can therefore not be made physical.

In more detail

The decision table test can be reinforced by the application of a boundary value analysis. This option is included as an extra condition in the creation of the logical test cases. In the example, this condition could be included in respect of the number of capsules and the distance. The requirement then is that for the “number of capsules” at least the values of 199, 200 and 201 should occur (e.g. in columns 9, 10 and 11) and for “distance” at least the values of 49, 50 and 51 (e.g. in columns 1, 2 and 7). The number of test cases does not change with this approach. Another possibility is to include a separate column for each value. This is a thorough method that tests all the combinations, but it is labour-intensive. The number of test cases increases with this approach.

4- Establishing the starting point

No remarks.

Example
The customer’s details that are relevant to the placing of an order should be present in the information system.

An overview of all featured Test Design Techniques can be found here.