Domain Analysis

What it is

Equivalence Partitioning and Boundary Value Analysis are single-variable techniques. They assume inputs can be partitioned and tested independently. But real systems rarely have truly independent inputs. A loan calculator might accept amounts from $1,000 to $500,000 — but the minimum loan amount changes based on the term selected. A shipping cost might depend on both weight and destination zone together, not each alone.

Domain analysis is the advanced technique for these situations. It treats the input space as a multi-dimensional domain where boundaries between valid and invalid regions are defined by the interaction of multiple variables, not by a single variable in isolation.

The technique gives precise names to points around a boundary (on-point, off-point, in-point, out-point) and requires that you test these specifically designed points for each relevant boundary — including boundaries that exist only because two or more variables combine.

Key terminology

Domain analysis uses four precise terms for points around a linear boundary:

• On-point — the value exactly on the boundary. If the boundary is “age ≥ 18”, the on-point is 18. This is always tested.
• Off-point — the value closest to the boundary on the other side. For “age ≥ 18” with integer values, the off-point is 17. This is always tested.
• In-point — any value well inside the valid partition (away from the boundary). For “age ≥ 18”, an in-point might be 30. Confirms the interior of the partition is handled correctly.
• Out-point — any value well outside the valid partition. For “age ≥ 18”, an out-point might be 5. Confirms rejection of clearly invalid values.

Standard BVA tests on-point and off-point for single variables. Domain analysis extends this to the combined boundaries created by multi-variable constraints.

Beyond single variables: inter-variable dependencies

Consider a system where the valid range of variable B depends on the value of variable A. This creates a constraint boundary in two-dimensional space — a line (or curve) in the A×B plane, not a single point on each axis.

Testing A and B independently misses every point that sits on or near this combined boundary. You need test cases designed specifically for the interaction — values of A and B chosen together so that their combination lands on, just inside, and just outside the constraint boundary.

For linear constraints (the most common case), the boundary is a straight line in the input space. Domain analysis requires test points on each side of this line plus a point on the line itself.

Worked example: loan calculator

A loan calculator has two inputs:

• Loan amount: $1,000 – $500,000
• Term: 1 – 30 years

Additional constraint from the spec: “Loans under $10,000 are only available for terms of 1–5 years.” This creates a cross-variable boundary: when amount < $10,000, term must be ≤ 5. Standard EP/BVA on each variable individually would not surface this constraint.

The rows labelled Cross-boundary are the ones unique to domain analysis. They test the constraint that exists only because two variables interact. EP/BVA on each variable individually would produce loan amount tests and term tests, but no test would ever combine $9,999 with a term of 6 years unless the tester deliberately reasoned about the inter-variable constraint.

Linear boundary analysis

When the constraint between two variables is expressed as a linear inequality (e.g., amount < $10,000 AND term ≤ 5 years), the boundary in the two-dimensional input space is a pair of line segments. Testing that boundary rigorously means:

1. Identify the corner points of the boundary region (the vertices of the polygon in A×B space that defines the constraint).
2. For each straight-line segment of the boundary, test at least one on-point (on the segment) and one off-point (just outside the valid region on the perpendicular to the segment).
3. Test each corner of the boundary region — these are the highest-risk points because they are at the intersection of two constraints simultaneously.

This systematic approach ensures you do not miss boundary behaviour caused by rounding, floating-point precision, or off-by-one errors in the constraint implementation.

ISTQB mapping

Domain analysis is an Advanced-level technique. The ISTQB CTAL-TA syllabus expects candidates to apply it at K4 (analyse): given a specification with inter-variable constraints, identify the domain boundaries and design test cases that systematically cover the on/off/in/out points of those boundaries.

Common mistakes

• Treating variables independently — running BVA on each input field separately and calling it done. If any constraint in the spec references two variables at once, you need domain analysis for that constraint.
• Missing constraint boundaries — constraints are often buried in spec footnotes, data dictionaries, or business rule tables. Do a focused read for any “if X then Y” language that involves two different inputs.
• Testing only the interior — developers are usually good at handling values deep inside the valid region. Bugs cluster at boundaries. Prioritise on-points and off-points over in-points and out-points.
• Using exact floating-point values as boundaries — if a constraint is computed (e.g., a percentage), find out whether the implementation uses integer arithmetic, decimal arithmetic, or floating-point. The on-point and off-point need to be designed relative to the implementation’s precision, not the spec’s idealised value.
• Skipping constraint analysis in agile — domain analysis applies equally to acceptance criteria as it does to formal spec documents. If a user story says “given X is < 10 and Y is > 5”, there is an inter-variable domain boundary. Test it.

Related techniques

Domain analysis is a direct extension of Equivalence Partitioning and Boundary Value Analysis. If you haven’t mastered those first, domain analysis will not make sense.

When multiple variables interact, the conditions between them are often expressible as a cause-effect relationship. Use Cause-Effect Graphing to model those relationships explicitly before designing the test points.

For systems with many interacting variables where full domain analysis would be prohibitively expensive, Pairwise Testing provides a combinatorial reduction strategy — pair domain analysis (applied to the highest-risk variable pairs) with pairwise coverage for the rest.

Cross-variable constraint: when weekly income > $800, hours worked must be >= 30. The two fields are linked — the valid range of hours depends on the income value.

The boundary in income x hours space: it is a line (an L-shaped region edge), not a point. Specifically, the constraint only bites once income crosses $800; on the high-income side, the valid region is cut off below 30 hours.

Why single-variable EP/BVA misses it: testing income alone (e.g. $799, $800, $801) and hours alone (e.g. 29, 30, 31) never forces the two values to be chosen TOGETHER. A test of "income $1,000" might be paired with a perfectly valid 40 hours; a test of "29 hours" might be paired with a low income. No single-field test ever lands on the combination "income $1,000 with 20 hours", which is the case the rule was written to reject.

Correct labelling for the boundary "age 18 to 65 inclusive" (lower boundary = 18):
- Age 18 — on-point — Accepted (the value exactly on the boundary; inclusive, so it is valid)
- Age 17 — off-point — Rejected (the value closest to the boundary on the invalid side)
- Age 40 — in-point — Accepted (well inside the valid partition)
- Age 90 — out-point — Rejected (well outside the valid partition)

What was wrong with the original:
- 18 was called off-point/Rejected: it is the ON-point and, because the range is inclusive, it must be ACCEPTED.
- 17 was called on-point/Accepted: it is the OFF-point and must be REJECTED.
- 40 was called out-point/Accepted: the result was right but the label was wrong — 40 is an IN-point.
- 90 was called in-point/Rejected: the result was right but the label was wrong — 90 is an OUT-point.
The original effectively swapped on/off and in/out throughout.

Balance $50,000, so the rule "leave at least $1,000" means maximum withdrawal = $49,000.

- On-point:  withdraw $49,000 — Accepted (leaves exactly $1,000; boundary is inclusive)
- Off-point: withdraw $49,001 — Rejected (would leave $999, one dollar under the floor)
- In-point:  withdraw $20,000 — Accepted (leaves $30,000; well inside the allowed region)
- Out-point: withdraw $50,000 — Rejected (leaves $0; clearly violates the retain-$1,000 rule)

The point that single-variable testing would miss is the on/off pair at $49,000 / $49,001. The withdrawal limit is not a fixed number — it is defined by the balance, so the boundary moves with the other variable. A senior would also test a second balance (e.g. $5,000, max withdrawal $4,000) to confirm the limit tracks the balance correctly, and would check the exact inclusive/exclusive wording of "at least $1,000".

Self-Check