Using decision tables for test design
The first task is to identify a suitable function or subsystem that has a behavior which reacts according to a combination of inputs or events.
Credit card worked example
The conditions and actions are listed in the left hand column. All the other columns in the decision table each represent a separate rule, one for each combination of conditions.
We may choose to test each rule/combination and if there are only a few this will usually be the case. However, if the number of rules/combinations is large we are more likely to sample them by selecting a rich subset for testing.
Note that we have put X for the discount for two of the columns (Rules 1 and 2) - this means that
this combination should not occur.
You cannot be both a new customer and already hold a loyalty card! There should be an error message stating this, but even if we don't know what that message should be, it will still make a good test.
We have made an assumption in Rule 3. Since the coupon has a greater discount than the new customer discount, we assume that the customer will choose 20% rather than 15%.
We cannot add them, since the coupon cannot be used with the 'new customer' discount. The 20% action is an assumption on our part, and we should check that this assumption (and any other assumptions that we make) is correct, by asking the person who wrote the specification or the users.
For Rule 5, however, we can add the discounts, since both the coupon and the loyalty card discount should apply (at least that's our assumption).
Rules 4, 6 and 7 have only one type of discount and Rule 8 has no discount. so 0%.
If we are applying this technique thoroughly, we would have one test for each column or rule of our decision table.
The advantage of doing this is that we may test a combination of things that otherwise we might not have tested and that could find a defect. However, if we have a lot of combinations, it may not be possible or sensible to test every combination.
If we are time constrained, we may not have time to test all combinations. Don't just assume that all combinations need to be tested; it is better to prioritize and test the most important combinations.
Having the full table enables us to see which combinations we decided to test and which not to test this time. There may also be many different actions as a result of the combinations of conditions. In the example above we just had one: the discount to be applied.
The decision table shows which actions apply to each combination of conditions. In the example above all the conditions are binary, i.e. they have only two possible values: True or False (or, if you prefer Yes or No).
Often it is the case that conditions are more complex, having potentially many possible values. Where this is the case the number of combinations is likely to be very large, so the combinations may only be sampled rather than exercising all of them.
Comments
Post a Comment