Start typing keywords to search the site. Press enter to submit.
Generative AI
Cloud
Testing
Artificial intelligence
Security
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.
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.
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.
ExampleThe 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.
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:
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.
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:
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.
Now that both conditions and results are known, the decision table is filled in in accordance with multiple condition coverage.
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).
Test design techniques