Testing messaging with a decision table

Decision Table

Recently I was testing the messages sent from an app to the user when I noticed that the messages were dependent on the interaction of three conditions. I used a decision table to analyse the messaging because decision tables show how many tests are required to test something that is affected by a group of conditions . 

In an earlier post I gave the steps for creating a decision table.

I had thought that decision tables would be useful for testing API endpoints. I have learned that testing messaging would be another use for decision tables. In the scenario I was testing there were three conditions. I found that all the three conditions could be true or false and that the message contained varied depending on whether each of the three conditions were true or false. Analysing this problem was most easily done with a decision table as the actions defined by the table would be the tests for the messages the app creates. 

Decision tables have one row for each condition. The number of rules in a decision table is 2 to the power of the number of conditions. There were three conditions so I would need eight columns for the rules. The actions in the table would cover all the test cases. What I needed to do was ensure that I had listed the conditions correctly as the decision table would then show me how many actions were required to test the messages. See the image above for an example of the decision table.

When I had created a decision table and I could execute the tests in the table. The decision table would ensure that I defined tests for each of the possible variations of the three conditions.

I shared my decision table with my team to help them in their work as I don’t want to find bugs, I want to help prevent them. 

Using a decision table had a number of advantages. It ensured that the tests covered all the functionality as I knew that I had covered all the conditions. It also gave me something I could share with the developers and help them in their developer testing which would mean that there are less bugs for me to find.

Further Reading: Computer Science 4th Edition by C. S. French

Published by Mike Harris

Mike has been working in testing for 20 years and is currently the lone tester for Geckoboard. He has been a Test Lead and has also worked as a part of waterfall, lean and agile teams. He is also Programme Secretary of BCS SIGiST. Mike has a B.Sc.(HONS) from Middlesex University and is an Associate of the University of Hertfordshire. He has set up and led a Testing Community of Practice and been part of a successful agile transition. He is Co-Programme Chair of the British Computer Society’s Specialist Interest Group in Software Testing. He also contributed to the e-book Testing Stories and has had articles published by the Ministry of Testing. Follow Mike on Twitter: @TestAndAnalysis

Join the Conversation

1 Comment

Leave a comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create your website with WordPress.com
Get started
%d bloggers like this: