What is a Decision Table Test?

In the toolbox of a software tester are eleven tools. The tester uses them all regularly. Prior to a task, he or she carefully examines which tools are needed. This is how you can best see the so-called test design techniques: as pieces of tools in the toolbox of a software tester.

Test design techniques

A Decision Table Test (BTT) is one of eleven test design techniques. A software tester is concerned with testing all kinds of software, such as applications. Of course, each case is different and each software test has a different purpose. When the purpose of a test is known to the software tester, he or she starts to look into an appropriate technique. A choice of the eleven design techniques must be made.

Each test design technique is different and differs from the others in the following ways:

• What is needed to run the test
• What exactly you are going to test; the purpose of the test.
• The test base: all documents that describe how the software should work.

And when the time comes, a tester might well choose the Decision Table test to examine software with.

What can you test with a Decision Table test?

With the BTT, you test the detailed functionality of software. Online sources tell us that it is a "thorough technique" for testing functionality. The Decision Table Test focuses on examining so-called conditions. That's a term you'll hear repeatedly as a software tester, so we'll define the term below.

What are conditions?

Conditions are inextricably linked to decision points. There are two types of conditions: single and compound.

Single conditions

We'll start at the beginning. A singular condition is best explained using an example. Suppose you start up a job app and a question appears on the screen. The question is: Do you have a valid HBO diploma? There are two possible answers to the question: Yes or no. With a "Yes" you get access to the app and with the negative answer you don't.

The subsequent system behavior depends on one answer.

Composite conditions

With composite conditions, things are different. For a decision point with a composite condition, there can be multiple answers. The answers are connected to each other and the subsequent system behavior depends on multiple answers. We'll use the same example for this as we just did, but extend it a bit. Suppose you open the app and a longer question appears on the screen: Do you have a valid HBO degree and/or 5 years of work experience within a sales function?

This question is not easy to answer. It could be that you have a college degree but no work experience. The system must then admit you. So you see that the relationship between the answers also plays a role. The system behavior - whether or not to allow access to the app - must take into account four possible scenarios. That's an example of a composite condition.

Want to know more?

Hopefully by now the usefulness of the BTT has become more apparent to you. Want to learn more about test design techniques and software testing? TestLearning offers online courses that help you develop into a professional. Our e-learnings can be used flexibly: you learn when and where it suits you. Curious? At our course offering you can see what we can do for you!

Want to know more about Testlearning?

Would you like to be kept up to date with developments around our test training courses? Then follow us on LinkedIn, sign up for the monthly newsletter or read our blogs!