What is a Decision Table Test?
Within TMAP software testing, there are eleven design techniques. In this blog, we explain what the Decision Table Test (BTT) is. What can you test with it? What exactly do you test? These are questions that will be answered below. Did you get curious for the answers? You will know after reading this blog!
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.
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.
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!