angryweasel
Andrew Schiano
brucecrms
herrickspencer
kristianjaeger
Prakash
qingsongyao
ramonarjona
Rob T
Decision tables are an effective tool for describing complex functional requirements and designing test cases. Yet, although they’re far from a new concept, I’ve only seen a handful of functional specs and test plans that included one. The best way to illustrate their effectiveness is by regaling you with a tale of when one wasn’t used.
The year was 2009. Barack Obama was recently inaugurated as the 44th President of the United States, and the Black Eyed Peas hauntingly poetic Boom Boom Pow was topping the Billboard charts. I was the lead tester on a new security feature for our product.
Our software could be installed on six server types. Depending the server type and whether it was a domain controller, eleven variables would be set. The project PM attempted to describe these setting combinations in paragraph format. The result was a spec that was impossible to follow.
I tried designing my test cases from the document, but I wasn’t convinced all possible configurations were covered. You know how poor programming can have “code smell“? Well, this had “spec smell”. I decided to capture the logic in a decision table.
According to the always-reliable Wikipedia, decision tables have been around since ancient Babylon. However, my uncle, Johnny “Dumplings”, who is equally reliable, insists they’ve only been around since Thursday. I suspect the true answer lies somewhere in between.
If you’re not familiar with decision tables, let’s go through a simple example. Assume your local baseball squadron offers free tickets to kids and discounted tickets to senior citizens. One game a year, free hats are given to all fans.
To represent this logic in a decision table, create a spreadsheet and list all inputs and expected results down the left side. The inputs in this case are the fan’s age and sex. The expected results are ticket price and hat color.
Each row of a decision table should contain the different possible values for a single variable. Each column, then, represents a different combination of input values along with their expected results. In this example, the first column represents the expected results for boys under 5 — “Free Admission” and “Blue Hat”. The last column shows that female senior citizens get $10 tickets and a pink hat.
| Rule 1 | Rule 2 | Rule 3 | Rule 4 | Rule 5 | Rule 6 | |
| Inputs | ||||||
| Age < 5 | Y | Y | ||||
| 5 =< Age < 65 | Y | Y | ||||
| Age >= 65 | Y | Y | ||||
| Sex | M | F | M | F | M | F |
| Results | ||||||
| Free Admission | Y | Y | ||||
| $10 Admission | Y | Y | ||||
| $20 Admission | Y | Y | ||||
| Blue Hat Giveaway | Y | Y | Y | |||
| Pink Hat Giveaway | Y | Y | Y |
There are three major advantages to decision tables.
- Decision tables define expected results for all input combinations in an easy-to-read format. When included in your functional spec, decision tables help developers keep bugs out of the product from the beginning.
- Decision tables help us design our test cases. Every column in a decision table should be converted into at least one test case. The first column in this table defines a test for boys under 5. If an input can be a range of values, however, such as “5 =< Age < 65”, then we should create tests at the high and low ends of the range to validate our boundary conditions.
- Decision tables are effective for reporting test results. They can be used to clearly show management exactly what scenarios are working and not working so informed decisions can be made.
It’s important to note that decision tables only work if the order the conditions are evaluated in, and the order of the expected results, doesn’t matter. If order matters, use a state transition diagram instead. I’ll blabber about them in a future article.
Getting back to my story, I used the spec to fill in a decision table representing all possible server combinations and expected results. The question marks in the table clearly showed that results weren’t defined for several installation configurations. I brought this to the Program Manager’s attention, and we will able to fill in the blanks to lock down the requirements.
| Case 1 | Case 2 | Case 3 | Case 4 | Case 5 | Case 6 | Case 7 | Case 8 | Case 9 | Case 10 | |
| Inputs | ||||||||||
| Server Type | Type 1 | Type 1 | Type 2 | Type 2 | Type 3 | Type 3 | Type 4 | Type 4 | Type 5 | Type 6 |
| DC | Y | N | Y | N | Y | N | Y | N | * | * |
| Results | ||||||||||
| Setting1 | Y | Y | Y | Y | Y | ? | N | N | N | N |
| Setting2 | Y | ? | Y | Y | Y | ? | N | N | N | N |
| Setting3 | Y | Y | Y | Y | Y | ? | N | N | N | N |
| Setting4 | Y | Y | Y | Y | Y | ? | N | ? | N | N |
| Setting5 | Y | Y | Y | Y | Y | ? | N | N | N | N |
| Setting6 | Y | Y | Y | Y | Y | ? | N | N | N | N |
| Setting7 | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? |
| Setting8 | N | N | N | N | N | ? | Y | Y | N | N |
| Setting9 | ? | N | N | N | N | ? | Y | N | N | N |
| Setting10 | N | N | ? | Y | Y | ? | N | N | ? | N |
| Setting11 | N | N | Y | Y | Y | ? | N | N | N | N |
This easy-to-understand table took the place of 2 full pages of spaghetti text in the functional spec. As a result, the developers had a comprehensive set of requirements to work off of, and I had designed a thorough set of test cases to validate their work. Boom Boom Pow, indeed!
Filed under: Test Planning | Tagged: Decision Tables, State Transition Diagrams, Test Planning |
Expert Testers 
Using decision tables, state machines, and organized techniques like this can be a great way to make specs less ambiguous and find design problems in the spec phase. It sounds like you made this a learning experience for your team as well!
Decision tables are good however due to time restrictions it is impossible to test all the combinations therefore I preper to design test cases cleverly covering all conditions executing a minimum of test cases. They become very complicated in the data migration projects.
Where there are 100 columns and each column has its own rule of transformation say on an average each column has 5 different business rules imagin how many test cases would you write. You have to work smartly having minimum test cases covering all conditions. How? I don’t have time to cover it here.
Good Luck
Even then using decision table will have better coverage with less documentation.
Great examples. We use HP’s QTP to drive our tests. You can feed input (i.e. values for variables) from Excel spreadsheets. Wonder if this approach would work for that?.Has anyone ever tried this? I asked my Uncle Gianni Screwball, who also thinks he knows everything, had nuthin for me on this.
Marc, I think our uncles may know each other.
A cool new Crowdfunding project for free web based decision table processor for testing logic and bus. rules here: http://goo.gl/5dyzC
[…] [6] https://experttesters.com/2012/12/03/decision-table-testing/ […]
Hello admin, i must say you have hi quality content here.
Your blog should go viral. You need initial traffic boost only.
How to get it? Search for; Mertiso’s tips go viral