Detecting Defects in Decision Tables and with Model-Based Testing (ISTQB CTAL-TA)
Overview
In the ISTQB Advanced Level Test Analyst (CTAL-TA) syllabus, the chapter on Software Defect Prevention asks the Test Analyst to do more than test running software. It expects you to find defects in the test basis (requirements, user stories, business rules, specifications) before any code exists.
Two practical ways to do this are:
1. Building and analysing decision tables.
2. Building and analysing models, such as state transition diagrams, activity diagrams and BPMN process models. These are the models used in Model-Based Testing (MBT).
The key insight is that the act of formalising a specification into a table or model is itself a static testing activity. While you build the model, gaps, contradictions and ambiguities become visible.
Why It Is Important
1. Phase containment. The syllabus places this topic under 'supporting phase containment'. The goal is to find a defect in the same phase in which it was introduced. A missing business rule found during analysis costs minutes to fix. The same rule found in production can cost days, money and reputation.
2. Prevention, not just detection. A defect fixed in the specification never becomes a defect in the code. That is true defect prevention.
3. Specification defects multiply. One ambiguous rule can be interpreted differently by developers, testers and business users. This causes many downstream failures and disputes.
4. Test design and defect detection happen together. The table or model you build to find specification defects is the same artefact you later use to derive test cases. The effort pays off twice.
5. Objectivity. Decision tables and formal models give measurable criteria, such as the number of rules or reachable states. This is more reliable than simply reading a document and 'feeling' that something is missing.
What It Is
Decision tables
A decision table represents business logic as:
- conditions (inputs or circumstances),
- actions (outcomes),
- rules (columns, each a combination of condition values with its resulting actions).
When a Test Analyst converts a textual specification into a decision table, three main classes of specification defects can be detected:
- Incompleteness (missing rules): combinations of conditions for which the specification defines no action.
- Inconsistency or contradiction: the same combination of conditions leads to different actions in different parts of the specification.
- Redundancy or overlap: two rules cover the same combination and give the same action. This is not always a failure, but it is a maintainability and clarity issue. It may also hide a contradiction.
Ambiguity is also exposed. If you cannot decide whether a condition value is true or false for a given case, the requirement is ambiguous.
Models and Model-Based Testing
MBT uses a (semi-)formal model of the required behaviour of the test object to support test analysis, design and often automated test generation. Typical models include:
- state transition diagrams and tables,
- UML activity and sequence diagrams,
- BPMN process models,
- decision models (for example, DMN).
Creating, reviewing, simulating or tool-checking these models reveals specification defects such as:
- Unreachable states: no path leads to them from the initial state.
- Dead-end (trap) states: non-final states with no outgoing transitions.
- Missing transitions: an event is not handled in a given state, which shows up as an empty cell in a full state table.
- Non-determinism: the same event in the same state leads to different target states without mutually exclusive guards.
- Overlapping or incomplete guard conditions: for example, 'amount > 100' and 'amount < 100', with nothing defined for exactly 100.
- Missing initial or final states, or loops with no exit.
- Inconsistency between models or views: for example, a sequence diagram sends a message that the state model never accepts.
- Deadlocks, livelocks and violated properties (safety or liveness). These are found by simulation or model checking.
How It Works
Step-by-step approach with decision tables
1. Identify all conditions and their possible values from the specification.
2. Calculate the theoretical number of combinations. This is the product of the number of values of each condition. For n Boolean conditions it is 2 to the power n.
3. Map every rule stated in the specification into a column.
4. Check completeness. If the mapped rules cover fewer combinations than the theoretical total, rules are missing.
5. Check consistency. If two columns share the same condition values but have different actions, there is a contradiction.
6. Check redundancy. If two columns share the same condition values and the same actions, they are duplicates.
7. For collapsed tables with 'don't care' entries ('-'), count how many full combinations each column covers. A '-' on a Boolean condition doubles the count. If the total covered is greater than the theoretical total, some columns overlap. Inspect them for contradiction or redundancy. If the total is less, rules are missing.
8. Check for infeasible combinations. Some combinations may be impossible, such as 'age < 18' with 'retired = yes'. Confirm these with stakeholders rather than silently ignoring them.
9. Raise every finding as a specification defect or a question to the author or business owner.
Worked example
The specification says:
'Members ordering over 100 EUR get free shipping. Non-members ordering over 100 EUR pay 5 EUR shipping. Members always get free shipping. Non-members ordering 100 EUR or less pay 10 EUR.'
The conditions are Member (Y/N) and Order > 100 (Y/N). This gives 4 combinations.
- Rule 1: Y, Y → free.
- Rule 2: N, Y → 5 EUR.
- Rule 3: Y, - → free. This covers (Y,Y) and (Y,N).
- Rule 4: N, N → 10 EUR.
Coverage counts are 1 + 1 + 2 + 1 = 5, but only 4 combinations exist. So there is an overlap. Rule 1 and Rule 3 both cover (Y,Y) with the same action, which is redundancy. If Rule 3 had said '2 EUR', it would be a contradiction. No combination is missing, so the specification is complete.
Also notice the wording '100 EUR or less' versus 'over 100'. Boundary wording like this is worth verifying for ambiguity.
Step-by-step approach with models (MBT)
1. Select a modelling notation suited to the behaviour:
- states and events → state machine,
- workflows → activity diagram or BPMN,
- rules → decision table.
2. Build the model from the test basis. Every place where you must guess or ask a question is a potential defect.
3. Convert the state diagram into a full state table (every state × every event). Empty cells show missing or undefined behaviour, often invalid transitions that the specification never mentions.
4. Check structural properties:
- reachability of all states from the initial state,
- a path from each state to a final state,
- deterministic transitions,
- complete, non-overlapping guards.
5. Review the model with stakeholders. Models are easier for business users to validate than long text.
6. Where tools exist, use syntax and consistency checking, simulation or animation, and model checking to find deadlocks or violated properties automatically.
7. Report the defects and update the specification and the model.
8. Use the corrected model to generate test cases, for example to achieve state or transition coverage.
Worked state example
An order can be: Created, Paid, Shipped, Cancelled, Delivered. The specification describes these transitions:
- Created → Paid (pay),
- Paid → Shipped (ship),
- Shipped → Delivered (deliver),
- Created → Cancelled (cancel).
Analysis reveals:
- Can a Paid order be cancelled? The cell (Paid, cancel) is undefined, so behaviour is missing.
- What happens on 'pay' in state Shipped? The specification is silent on invalid events.
- If the specification also says 'Paid orders may be refunded', but no Refunded state exists, the model is inconsistent with the text.
- If a state 'OnHold' is mentioned but no transition leads to it, it is unreachable.
Benefits and limitations to remember
Benefits:
- early detection,
- objective completeness checks,
- reusable test design artefacts,
- better communication with stakeholders,
- automation potential in MBT.
Limitations:
- a model is only as good as the understanding behind it, and the modeller can introduce defects,
- modelling requires skills and tools,
- large decision tables suffer from combinatorial explosion,
- models are abstractions and will not detect every defect type (for example, performance or usability issues),
- models need maintenance when requirements change.
Exam Tips: Answering Questions on Detecting Defects in Decision Tables and with Model-Based Testing
1. Know the K-level. Using a model to detect specification defects is a K3 (apply) objective. Expect a scenario with a short specification or a partial table or diagram. You will be asked to identify the defect, count missing rules, or choose the correct finding.
2. Memorise the three decision table defect types: missing rules (incomplete), contradictory rules (inconsistent) and duplicated rules (redundant). Questions often present options that confuse these. Read carefully:
- same conditions + different actions = contradiction,
- same conditions + same actions = redundancy,
- combination not covered = missing rule.
3. Always compute the theoretical number of combinations first. Multiply the number of values per condition, for example 2 × 2 × 3 = 12. Then add up the combinations each column covers. Remember that a '-' on a condition with k values multiplies coverage by k.
4. Coverage sum rules:
- sum < total → rules are missing,
- sum > total → overlap exists, so check whether it is a contradiction or a redundancy,
- sum = total → you can still have both an overlap and a missing rule, so verify each combination individually when the numbers are small.
5. For state models, think 'full state table'. If a question asks how to find missing behaviour, the answer is usually to check every state–event pair. Unreachable states, dead-end states and non-deterministic transitions are classic correct answers.
6. Remember that modelling is static testing. Defects are found without executing the test object. If an option says the defect is found 'when the generated tests are executed', it is usually wrong when the question is about specification defects.
7. Link to phase containment. If asked why a Test Analyst should model the specification early, choose answers about finding defects in the phase where they were introduced, reducing cost and preventing defects from propagating.
8. Beware of absolute distractors. Statements such as 'MBT removes the need for reviews', 'a complete decision table guarantees correct code' or 'models detect all defect types' are false.
9. Distinguish infeasible from missing. An impossible combination is not automatically a defect. However, the best answer usually involves confirming it with stakeholders rather than ignoring it.
10. Look for ambiguity at boundaries. Wording like 'more than', 'at least' or 'up to' combined with guards often hides a gap or overlap at the boundary value. This is a frequent trap in scenario questions.
11. Consistency across artefacts. If a question shows two models (for example, a state diagram and a use case), check whether an event or state appears in one but not the other. Cross-model inconsistency is a valid defect.
12. Manage your time. For K3 questions, sketch the table or state matrix on your scratch paper. Drawing a 2 × 2 or 2 × 2 × 2 grid takes seconds and prevents counting errors.
Summary
Decision tables and MBT models turn informal specifications into structured artefacts that can be checked objectively.
- Decision tables expose missing, contradictory and redundant rules.
- State and process models expose unreachable or dead-end states, missing transitions, non-determinism, guard gaps and cross-model inconsistencies.
Doing this early supports phase containment and true defect prevention. In the exam:
- calculate combinations,
- classify the defect type precisely,
- remember that the value lies in finding defects before execution.
