Defects Revealed by Data-Based, Behavior-Based and Rule-Based Models (ISTQB CTAL-TA)
Overview
In the ISTQB Advanced Level Test Analyst (CTAL-TA) syllabus, the topic of software defect prevention stresses that a Test Analyst can find defects before any code exists. One of the most effective ways to do this is to build models of the test object while analysing the test basis (requirements, user stories, specifications). Building a model forces you to make every element explicit. Gaps, contradictions and ambiguities that are easy to miss in prose become visible.
The syllabus groups these models into three families:
1. Data-based models
2. Behavior-based models
3. Rule-based models
Each family tends to reveal its own typical kinds of defects. The exam expects you to match a model type to the defects it reveals.
Why It Is Important
- Shift-left and phase containment: defects found in the specification are much cheaper to fix than defects found in system testing or production. Modeling supports phase containment, which means removing a defect in the same phase it was introduced.
- Prevention, not only detection: a clarified requirement stops developers from implementing the wrong thing.
- Dual value: the same model later drives test design. Data models feed equivalence partitioning and boundary value analysis. State models feed state transition testing. Decision tables feed decision table testing. Modeling effort is therefore never wasted.
- Communication: models give business analysts, developers and testers a shared, unambiguous view, which reduces misunderstandings.
- Exam relevance: scenario-based questions often describe a model and an anomaly found in it, then ask which model type was used or which defect type was revealed.
What It Is: The Three Model Families
1. Data-Based Models
Focus: the data the system stores, receives, transforms and outputs, including its structure, types, ranges and relationships.
Examples:
- Entity-relationship diagrams
- Domain and class models
- Data dictionaries
- Data flow diagrams
- Equivalence partition and boundary models
- Input/output data specifications
Typical defects revealed:
- Missing or undefined data elements, such as a field referenced but never defined.
- Incorrect or inconsistent data types, formats or units, such as a date treated as text in one place and as a date in another.
- Undefined or overlapping valid and invalid ranges (partitions), and missing or ambiguous boundaries, such as "less than 18" in one requirement and "18 or younger" in another.
- Wrong or missing relationships and cardinalities, such as an order that can exist without a customer.
- Data that is created but never used, or used but never created (data lifecycle and data flow anomalies).
- Inconsistent naming of the same data item across requirements.
- Missing handling of null, empty or default values.
2. Behavior-Based Models
Focus: how the system behaves over time and in response to events. This covers sequences, states, transitions and workflows.
Examples:
- State transition diagrams and tables
- Activity diagrams and flowcharts
- Use cases and scenarios
- Sequence diagrams
- Business process models (e.g., BPMN)
- User journeys
Typical defects revealed:
- Missing states or missing transitions, such as no defined reaction to an event in a given state.
- Unreachable states, which no transition leads to.
- Dead-end states with no exit when one is required, and deadlocks.
- Undefined events or invalid transitions that are not handled.
- Non-determinism, where the same event in the same state leads to different target states with no distinguishing condition.
- Incorrect or illogical sequences, such as payment being possible before checkout.
- Missing alternative or exception flows in use cases, such as timeout, cancel or error paths.
- Infinite loops and missing termination conditions.
3. Rule-Based Models
Focus: business logic. These models capture which conditions lead to which actions or outcomes.
Examples:
- Decision tables
- Cause-effect graphs
- Decision trees
- Business rule catalogues
- Logical expressions and truth tables
Typical defects revealed:
- Incompleteness: combinations of conditions with no defined outcome, such as a member with a coupon on a sale item.
- Contradictions or inconsistencies: the same combination of conditions leading to different actions in different rules.
- Redundancy: duplicate or overlapping rules.
- Ambiguous conditions: conditions that are not clearly true or false, such as "large order".
- Impossible combinations that are not identified as infeasible.
- Missing default or "else" rules.
- Unclear precedence or priority between rules.
How It Works in Practice
1. Select the model that suits the dominant characteristic of the test object:
- data-heavy items, such as forms, databases and interfaces, suit a data-based model;
- workflows, protocols and lifecycles suit a behavior-based model;
- calculations, eligibility and pricing logic suit a rule-based model.
Complex systems often need more than one.
2. Build the model from the test basis. Every element in the model must be traceable to a requirement. Where the model needs information the test basis does not provide, you have found a potential defect: an omission or ambiguity.
3. Analyse the model systematically:
- in a state table, fill every state/event cell;
- in a decision table, check that all 2^n combinations are covered and consistent;
- in a data model, check types, ranges, relationships and lifecycle.
4. Report the anomalies to the authors, for example in a review or refinement session. Requirements are corrected before implementation.
5. Reuse the model to derive test conditions and test cases. The model also provides coverage criteria.
Mini example: a requirement says that a gold member gets 10% off and orders over 100 get free shipping. Building a decision table with the conditions Gold (Y/N) and Over100 (Y/N) immediately shows two gaps. It is not stated whether the discount and free shipping combine, and the rule for exactly 100 is unclear. The first is a rule-based incompleteness. The second is a boundary ambiguity, which a data-based model would also reveal.
Exam Tips: Answering Questions on Defects Revealed by Data-Based, Behavior-Based and Rule-Based Models
1. Use keyword mapping.
- Words such as type, format, range, field, value, entity, relationship, cardinality, boundary, partition, unused data point to a data-based model.
- Words such as state, transition, event, sequence, flow, workflow, unreachable, dead end, loop, alternative path, use case point to a behavior-based model.
- Words such as condition, combination, rule, contradictory, inconsistent outcome, missing combination, redundant rule, decision table, business logic point to a rule-based model.
2. Identify the model from its artifact. Decision table or cause-effect graph means rule-based. State diagram, activity diagram or use case means behavior-based. ERD, data dictionary or class model means data-based.
3. Watch for distractors that swap defect types. For example, an option saying "a state transition diagram reveals contradictory business rules" is wrong. Choose the option where the defect naturally belongs to that model.
4. Remember the timing. These defects are found during test analysis and specification review, before execution. They are therefore usually defects in the test basis, not failures. Do not pick answers that describe failures observed when running code.
5. Distinguish "missing" carefully.
- A missing transition or state is behavior-based.
- A missing condition combination is rule-based.
- A missing data definition or range is data-based.
6. For "best" or "most appropriate" questions, choose the model that matches the dominant risk in the scenario. Examples: a loan eligibility calculation suits a rule-based model, an order lifecycle suits a behavior-based model, and a customer registration form with field validation suits a data-based model.
7. Treat non-determinism and contradiction as related but distinct. Non-determinism in the response to an event belongs to behavior models. Conflicting outcomes for the same conditions belong to rule models.
8. Expect benefit questions. Correct answers usually mention:
- early defect detection or prevention;
- improved clarity and testability of requirements;
- reuse of models for test design and coverage.
Be suspicious of options claiming models guarantee completeness or replace reviews entirely.
9. Apply K-level awareness. Questions are typically K2 (explain or classify) or K3 (apply to a scenario). For K3 questions, mentally sketch the model, such as a quick decision table or state table, and look for the gap.
10. Eliminate absolutes. Options containing "always", "only" or "all defects" are usually wrong.
Summary
- Data-based models reveal problems with what the data is.
- Behavior-based models reveal problems with when and in what order things happen.
- Rule-based models reveal problems with which conditions lead to which outcomes.
Master this three-way mapping and the typical defects in each family, and you can answer most exam questions on this topic quickly and confidently.
