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:

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

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 situations12..n
Condition 100..1
Condition 20~..0
Condition ..0..~0
Condition n01..0
Result 1X......
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.

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.

Example
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.


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 25 = 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 supplementIf 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 capsuleC2 Form of payment = “Direct debit”R1 Standard shipping costs := 0R2 Standard shipping costs := 10

Calculation of long-distance supplementC3 Distance < 50 km from UtrechtC4 Country = The NetherlandsR3 Long-distance supplement := 0R4 Long-distance supplement := 5R5 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
Since the total number of conditions amounts to four, the tester has decided to include these in one table*. The conditions list and the filling in of the tables according to multiple condition coverage deliver table 14.5 with test situations for the shipping costs example.

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).

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).