Tables

A decision table is a good way to deal with combinations of things (e.g. inputs). This technique is sometimes also referred to as a ’cause-effect’ table. The reason for this is that there is an associated logic diagramming technique called ’cause-effect graphing’ which was sometimes used to help derive the decision table (Myers describes this as a combinatorial logic network [Myers, 1979]). However, most people find it more useful just to use the table described in [Copeland, 2003].

• Decision tables provide a systematic way of stating complex business rules, which is useful for developers as well as for testers.
• Decision tables can be used in test design whether or not they are used in specifications, as they help testers explore the effects of combinations of different inputs and other software states that must correctly implement business rules.
• It helps the developers to do a better job can also lead to better relationships with them. Testing combinations can be a challenge, as the number of combinations can often be huge. Testing all combinations may be impractical if not impossible. We have to be satisfied with testing just a small subset of combinations but making the choice of which combinations to test and which to leave out is also important. If you do not have a systematic way of selecting combinations, an arbitrary subset will be used and this may well result in an ineffective test effort.

Why Decision table is important?

Decision tables are very much helpful in test design technique – it helps testers to search the effects of combinations of different inputs and other software states that must correctly implement business rules. Also, provides a regular way of stating complex business rules, that’s helpful for developers as well as for testers. Testing combinations can be a challenge, as the number of combinations can often be huge. It assists in development process with developer to do a better job. Testing with all combination might be unrealistic or unfeasible. We have to be happy with testing just a small subset of combinations but making the option of which combinations to test and which to leave out is also significant. If you do not have a efficient way of selecting combinations, an arbitrary subset will be used and this may well result in an ineffective test effort.

A decision table is basically an outstanding technique used in both testing and requirements management. It is a structured exercise to prepare requirements when dealing with complex business rules. Also, used in model complicated logic.

Way to use decision tables in test designing

Firstly; get to know a suitable function or subsystem that acts according to a combination of inputs or events. Taken system should be with fewer inputs or else combinations will become impossible. Always better to take maximum numbers of conditions, split them into subsets and use these subsets one at a time. After getting features that need to be combined, add them to a table showing all combinations of “Yes” and “No” for each of the feature.

Let’s take an example of a finance application, where users pay money – monthly Repayment or year wise (the term of loan). If user chooses both options, the system will create a negotiation between two. So, there are two conditions of the loan amount, mention in the given below table,

TABLE 1: Blank decision table

Conditions	Step 1	Step 2	Step 3	Step 4
Repayment money has been mentioned
Terms of loan has been mentioned

Next, recognize all of the combinations in “Yes” and “No” (In Table 2). In each column of two conditions mention “Yes” or “No”, user will get here four combinations (two to the power of the number of things to be combined). Note, if user has three things to combine, they will have eight combinations, with four things, there are 16, etc. Because of this, it’s always good to take small sets of combinations at once. To keep track on combinations, give alternate “Yes” and “No” on the bottom row, put two “Yes” and then two “No” on the row above the bottom row, etc., so the top row will have all “Yes” and then all “No” (Apply the same principle to all such tables).

TABLE 2: Decision table – Input combination

Conditions	Step 1	Step 2	Step 3	Step 4
Repayment money has been mentioned	Y	Y	N	N
Terms of loan has been mentioned	Y	N	Y	N

In the next step, recognize the exact outcome for each combination (In Table 3). In this example, user can enter one or both of the two fields. Each combination is sometimes referred to as a step.

TABLE 3: Decision table – Combinations and outcomes

Conditions	Step 1	Step 2	Step 3	Step 4
Repayment money has been mentioned	Y	Y	N	N
Terms of loan has been mentioned	Y	N	Y	N
Actions/Outcomes
Process loan money	Y	Y
Process term	Y		Y

At this time you didn’t think that what will happen when customer don’t enter anything in either of the two fields. The table has shown a combination that was not given in the specification for this example. This combination can result as an error message, so it is necessary to add another action (In Table 4). This will flash the strength this method to find out omissions and ambiguities in specifications.

TABLE 4: Decision table – Additional outcomes

Conditions	Step 1	Step 2	Step 3	Step 4
Repayment money has been mentioned	Y	Y	N	N
Terms of loan has been mentioned	Y	N	Y	N
Actions/Outcomes
Process loan money	Y	Y
Process term	Y		Y
Error message				Y

We will provide you some other example that allows the customer to enter both repayment and term. This will change the outcome of our table, this will generate an error message if both are entered (Shown in Table 5).

TABLE 5: Decision table – Changed outcomes

Conditions	Step 1	Step 2	Step 3	Step 4
Repayment money has been mentioned	Y	Y	N	N
Terms of loan has been mentioned	Y	N	Y	N
Actions/Outcomes
Process loan money		Y
Process term			Y
Error message	Y			Y

The final process of this method is to write test cases to use each of the four steps in our table.