Decision table testing: What is it and how does it work?

Software testing is an ongoing part of the software development life cycle. Your software is always under test. Some of those tests run automatically and may execute as part of your build process.

Sometimes those tests are manual, and performed by dedicated personnel like QA engineers. Beyond that, your customers are constantly testing your code as they utilize your software.

Some software is straightforward, and testing that software for correctness is itself straightforward. For other software, that isn’t true. There are applications which have a dizzying array of potential user inputs and states, and an equally dizzying list of correct outputs.

Regardless of the complexity of the software, it’s necessary for teams to validate the software with a variety of tests. Certain types of tests work better for different software behaviors. When you have complicated software with a wide array of inputs and states to consider, one of the more effective tools to reach for is the decision table test.

In this post, we’re going to outline what a decision table test is, how it works, and why it’s a tool you should use with your team.

What is decision table testing?

Decision table testing is a form of black box testing that works by creating a table of all combinations of state and input, then mapping those combinations to the correct outputs from the program.

Critically, this approach does not require automated tests, nor does it require manual execution of tests. It’s a type of testing that lives in both worlds, and it’s likely that for complicated software applications, you’ll need to utilize both manual and automated testing to comprehensively test the table.

While this testing method is often utilized for complicated applications, that’s not a requirement for adopting decision table testing.

If you have software that’s currently simple but you know that it will grow in complexity, developing the decision table early is a wise investment. It’s still easy to reason about, and you can expand it as you add more features to the software.

Decision table testing is a form of black box testing that works by creating a table of all combinations of state and input, then mapping those combinations to the correct outputs from the program.

How does decision table testing work?

Even though the software that it tests is complicated, the technique itself is not. In fact, it’s likely something that you already do to a lesser extent, without the formal structure around it.

The basic behavior of decision table testing is to map all of your possible inputs and states to their expected outputs. All of this goes together into a table. Then, in order to test the application, you follow the expected states + inputs and validate that you receive the expected output from the application.

Let’s look at an example. We’ll use the example of a phone app that will tell you whether or not a provided photo is of a hot dog. Here’s what an example decision table might look like for testing the app:

Example decision table

While our “Is It a Hot Dog” app is pretty simple, we can see the basic function of the decision table here. We have a list of inputs on the left side, then a list of expected inputs on the right side. And as we noted, this is a table that can be applied through manual testing or through automated testing.

Benefits of decision table testing

The primary benefit of decision table testing is that when done properly, it thoroughly validates the user-facing behaviors of your software. One tricky part of working with software is that the people who work on it every day can fixate on individual trees versus the entire forest.

This testing technique forces you to focus on the reality of the forest. In order to do a good job with this testing, you need to be comprehensive about all of the decisions that your software makes as your users interact with it.

As Fernando Doglio notes for Camunda, “This approach not only makes the rules easier to understand but also enables nontechnical stakeholders to contribute without needing to dive into complex code.”

Beyond the need to focus on the overall picture of how your software operates, decision table testing also brings along the benefits you gain from any kind of testing. You gain confidence that when you ship software, it works the way that you expect. You know that when you update your software, it still behaves the way that you and your users expect it to.

Getting started with decision table testing

Getting started with decision table testing is simple, and it’s something you can do today. One of the great parts about decision table testing is that you don’t need your decision table to be comprehensive.

You can absolutely build a decision table with just one input and one output. Then, as you update your software, you expand the decision table and create a test plan for each input.

If you want to do the best job with decision table testing, it makes a lot of sense to be comprehensive with your decision table. That will require some work, especially if you’re working with a mature codebase or a particularly complicated piece of software.

For particularly large codebases, it often makes sense to instead start with a decision table that outlines the behaviors of one segment of your application, since trying to cover the whole application can be daunting.

Again: this is just fine! A decision table covers every decision it defines and says nothing about parts it doesn’t include. The best decision tables are comprehensive, but if your decision table isn’t comprehensive, that doesn’t make the covered decisions any less valuable.

If you want to do the best job with decision table testing, it makes a lot of sense to be comprehensive with your decision table.

Best practices for decision table testing

If you’re thinking about picking up decision table testing for your team, here are some best practices to make sure that you’re doing the best job possible:

Be as thorough as you can

Every new test you add provides value. By being thorough, you help yourself every time you run your tests, and you also help other members of your team by concretely documenting the expected behaviors of your application.

Automate what you can

You don’t need to automate decision table testing. It’s not inherent to the concept. But the benefits of automated testing are numerous, and they’re no different for decision table testing versus any other testing strategy.

Don’t rely on decision table testing for the whole story

While decision table testing is a useful arrow in your testing quiver, it shouldn’t be the only arrow. If you only have decision table testing, whenever you ship an update that breaks existing behavior, you’ll have no information to go on other than your one black-box test.

Testing your application from a variety of angles makes it easier to isolate issues and fix them quickly.

Tricentis makes decision table testing easy

If you’re thinking about adopting decision table testing, Tricentis test automation makes spinning up your decision table tests and automating them for every build trivial.

Building a decision table and testing it once helps your team, but testing on every build means that you can ship your software with confidence that it’ll do what you and your users expect.

Tricentis handles all of the tough parts of test automation, meaning you can focus on the work of defining your decision tables and writing the tests to validate their outputs.

This post was written by Eric Boersma. Eric is a software developer and development manager who’s done everything from IT security in pharmaceuticals to writing intelligence software for the US government to building international development teams for non-profits. He loves to talk about the things he’s learned along the way, and he enjoys listening to and learning from others as well.