Domain Analysis
Domain analysis extends Equivalence Partitioning and Boundary Value Analysis to examine the relationships between variables. When a single variable’s partition isn’t enough because two inputs interact to define a boundary, domain analysis is the technique you need.
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.
When to reach for domain analysis: when the specification contains phrases like “if X and Y then…”, when a field’s valid range depends on another field’s value, or when an integration test fails at a combination that individual unit tests don’t cover. That gap is often a domain boundary between variables.
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.
| Test point type | Loan amount | Term (years) | Expected result | What it tests |
|---|---|---|---|---|
| On-point (amount lower) | $1,000 | 3 | Accepted | Minimum amount in valid range |
| Off-point (amount lower) | $999 | 3 | Rejected | Just below minimum amount |
| On-point (amount upper) | $500,000 | 25 | Accepted | Maximum amount in valid range |
| Off-point (amount upper) | $500,001 | 25 | Rejected | Just above maximum amount |
| On-point (term lower) | $50,000 | 1 | Accepted | Minimum term |
| Off-point (term upper) | $50,000 | 31 | Rejected | Just above maximum term |
| Cross-boundary: on-point | $9,999 | 5 | Accepted | Small loan at max allowed term |
| Cross-boundary: off-point | $9,999 | 6 | Rejected | Small loan one year over constraint |
| Cross-boundary: threshold | $10,000 | 6 | Accepted | Amount at threshold — constraint no longer applies |
| Cross-boundary: off threshold | $9,999 | 6 | Rejected | One dollar under threshold — constraint still applies |
| In-point | $100,000 | 15 | Accepted | Normal mid-range case |
| Out-point | $5,000 | 20 | Rejected | Small loan with long term — clearly invalid combo |
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:
- Identify the corner points of the boundary region (the vertices of the polygon in A×B space that defines the constraint).
- 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).
- 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.
Non-linear boundaries: if a constraint is expressed as a formula (e.g., monthly repayment must not exceed 40% of income), the boundary curve is non-linear. Domain analysis still applies, but you need to test at enough points along the curve to catch approximation errors in the implementation. Choose test points that put the computation result at, just below, and just above the threshold.
ISTQB mapping
| Syllabus ref | Topic | Level |
|---|---|---|
| CTAL-TA 3.2 | Domain analysis as advanced extension of EP and BVA; on-point/off-point/in-point/out-point terminology | Advanced / Senior |
| CTAL-TA 3.2 K4 | Analyse a specification to identify domain boundaries and design test cases covering on/off/in/out points | Advanced LO |
| CTFL 4.2.1–4.2.2 | Foundation prerequisite — EP and BVA must be understood before applying domain analysis | Foundation (prereq) |
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.
Practice this technique: Try Senior Practice 05 — Loading & async states.
Try It — Classify domain test points
A NZ KiwiSaver contribution calculator has this constraint: employees under 18 can only contribute 3% (not 4% or 8%). Age range: 16–65. Contribution rate options: 3%, 4%, 8%.
For each test case below, classify the point type and the expected result.
| Age | Rate | Point type | Expected result |
|---|---|---|---|
| 17 | 3% | ||
| 17 | 4% | ||
| 18 | 4% | ||
| 30 | 8% | ||
| 15 | 3% |
Answers
| Age | Rate | Point type | Result | Why |
|---|---|---|---|---|
| 17 | 3% | Cross-boundary on-point | Accepted | Under-18 at exactly 3% — constraint boundary is satisfied. Tests the on-point of the cross-variable rule. |
| 17 | 4% | Cross-boundary off-point | Rejected | Under-18 attempting 4% — one step outside the constraint. The off-point that should trigger the rule. |
| 18 | 4% | Cross-boundary on-point (age threshold) | Accepted | Age exactly at 18 — constraint no longer applies. The on-point of the age boundary itself. |
| 30 | 8% | In-point | Accepted | Well inside the valid region (adult, any rate). Confirms normal behaviour away from all boundaries. |
| 15 | 3% | Out-point (age) | Rejected | Below minimum age (16). Age itself is invalid — out-point on the age lower boundary. |
The critical tests are rows 1 and 2: 17@3% (accepted) and 17@4% (rejected). These test the cross-variable constraint boundary — the kind EP/BVA on each variable alone would miss entirely.