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.
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:
 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, pseudocode, 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 longdistance 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 longdistance 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 longdistance supplement of €5 is applied. If the delivery address is outside of the Netherlands, then a longdistance 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 longdistance supplement If the delivery address for the capsules is within a radius of 50 km from Utrecht, then no longdistance cost is applied. If the delivery address is 50 km or more from Utrecht, but still in the Netherlands, then a longdistance supplement of €5 is applied. If the delivery address is outside of the Netherlands, then a longdistance 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^{5} = 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 longdistance supplement C3 distance < 50 km from Utrecht

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 longdistance supplement If the delivery address for the capsules is within a radius of 50 km from Utrecht, then no longdistance supplement is applied. If the delivery address is 50 km or more from Utrecht, but still in the Netherlands, then a longdistance supplement of €5 is applied. If the delivery address is outside of the Netherlands, then a longdistance 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 longdistance supplement C3 Distance < 50 km from Utrecht C4 Country = The Netherlands R3 Longdistance supplement := 0 R4 Longdistance supplement := 5 R5 Longdistance 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.
Reading a table is often thought to be difficult. Test situation 7, for example, is read as follows: * _{This is irrelevant to the final number of combinations. Consider: in the shipping costs example, one table is created with four conditions in total. This leads to one table with maximum 24 = 16 combinations. In the example, the table could be split into two tables (“Calculation of standard shipping cost” and “Calculation of longdistance supplement”). Both tables would then consist of 22 = 4 test columns. Those, in combination with each other, would give 4*4, or 16 combinations. Since splitting or nor splitting the table makes no difference to the final result, it is advisable to split tables with more than five conditions into several tables, since this makes the individual tables clear and intelligible.} 
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: "Graycode"). 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 


Instead of filling in the decision table according to the basic technique of multiple condition coverage, a (more elementary) variant could be chosen at the stage when the strategy is being determined. This technique is applied both to the conditions and to the results. As an example, the "shipping costs calculation" table below has been filled in according to the condition/decision coverage.
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:
For more information on this, refer to "Nwise 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 notC4 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:
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):
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 labourintensive. 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.