A decision table is a special technique that helps users to properly combine the conditions from a product requirements document.

[highlight dark=”no”]Such a graphic table usually contains different requirements that should be taken into account while performing software testing.[/highlight]

The lower is the number of requirements, the lower will be the number of inconsistencies; and the lower is the number of discrepancies, the less time will be needed to fix something after implementing it.

In other words, if there are few requirements, it will be easier for a tester to write test cases.

In a software testing field, such tables are used primarily for creating flexible test cases on the basis of technical requirements.

And the most important information should be written using minimum text.

[highlight dark=”no”]A decision table is a kind of test design techniques, therefore, you will need to be familiar with it.[/highlight]

Further, we’ll analyze this term more thoroughly.

How we should create a decision table

It’s not hard since we use only vertical and horizontal columns.

So:

• Horizontally — a tester should write all conditions that affect the product’s behavior. Below — a result that should be achieved;
• Vertically — established requirements (all conditions) that should be used to work with a product we are testing.

Graphic representation of this:

	Rule 1	Rule 2	…	Rule X
Condition
Condition 1
Actions
Action 1

Its Advantages

• Visualization. Tables are more illustrative than texts. It’s easier to use a table and ask a developer to explain some project details than bring him/her long unclear texts;
• Creating a table equals writing a test case. The data from such a table can be considered positive test cases that should be executed primarily;
• Such visualization helps to find a defect in the documentation. This happens because an incorrect formula will be seen from the Moon;
• Tables help to have a fresh look at a product requirements document.

Disadvantages of a decision table

It has no serious flaws but this table is not needed if:

• A simple approach to software testing is used on a project;
• There is a lot of introductory information — you don’t need to create numerous columns with conditions. Numerous tests lead to a small profit since you can’t do without test analysis and this requires a lot of time and human resources spent.

Instead of conclusion

Such a tool as a decision table will be very useful if you use it to describe complex systems in a form of requirements:

• Any condition is introductory information;
• All actions entail an expected test result;
• Each column is a ready test case.