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.
1 The Hook
A Christchurch lender shipped a loan calculator. The amount field accepted $1,000 to $500,000 and was tested at both edges. The term field accepted 1 to 30 years and was tested at both edges. Each field, on its own, behaved perfectly. The tester signed it off.
Buried in a footnote of the spec was one extra rule: “Loans under $10,000 are only available for terms of 1–5 years.” That rule does not live on the amount axis or the term axis. It lives in the relationship between them. A customer asked for a $9,500 loan over 7 years — an amount that was individually valid and a term that was individually valid — and the system approved it, against the lender's own credit policy. Every single-field test passed. The bug sat on the diagonal line where the two fields meet, and no test had ever put $9,500 and 7 years in the same request.
This is what domain analysis is for. Boundary value analysis walks the edge of one variable at a time. But some boundaries only exist between variables — a line in two-dimensional space, not a point on one axis — and you can only test them by choosing the two values together, on purpose.
The most dangerous outcome of skipping domain analysis isn't a test that fails — it's a defect that never shows up until production. I've reviewed post-incident reports on NZ government portals where an Revenue NZ income-reporting form approved submissions it should have blocked. Every individual field test passed. The developers were confused; they called it an "environment issue." It wasn't. It was a cross-variable constraint — two income fields that were each valid alone but invalid in combination — that no test had ever placed in the same request. The tell-tale sign you're in this situation: a defect that can only be reproduced with two specific values at once, and your test suite has no case that pairs them deliberately.
2 The Rule
When a valid range for one input depends on the value of another, the boundary is a line in the combined input space — so test the points on that line (on-point), just across it (off-point), well inside it (in-point), and well outside it (out-point), choosing the variables together rather than one at a time.
3 The Analogy
A fishing rule that depends on two measurements at once.
A snapper regulation on the Hauraki Gulf might say: you may keep the fish if it is at least 30 cm long, but undersized fish are allowed only if you have caught fewer than your daily bag. Checking length alone tells you nothing — a 29 cm fish is fine for one angler and an offence for another, depending on how many are already in the bin. The rule is a line drawn across two measurements together: size and count. A fisheries officer who only ever held the ruler against the fish, and never counted the catch, would miss exactly the cases the rule was written to catch.
Domain analysis is measuring both at once and standing right on the line where the combined rule flips from legal to illegal. The single-variable check — just the ruler — can never find that boundary.
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.
4 Industry Reality
- The constraint is nowhere in the spec. The most common real-world scenario: the inter-variable dependency was never written down. You find it by questioning a product owner, reading a legacy data dictionary, or reverse-engineering a constraint from a production defect. Domain analysis starts with discovery, not just test design.
- Business rules live in footnotes and email threads, not user stories. In NZ finance and government projects (Revenue NZ, CoverNZ, Kainga Ora portals), cross-variable constraints often exist only in PDFs attached to Jira comments or in a domain expert's head. Senior testers learn to run a structured "what else depends on this field?" conversation before writing a single test.
- Floating-point arithmetic is the silent enemy. The spec says "loans under $10,000" but the implementation stores amounts as floating-point. The on-point is not $9,999.00 — it may be $9,999.001 due to rounding. Experienced testers ask the developer what arithmetic the implementation uses before finalising on/off values.
- Legacy codebases add undocumented constraints over time. A constraint written in a 2009 policy document, implemented in 2011, and patched twice since then may have drifted. The live system enforces a slightly different boundary than any spec. Senior testers verify the actual behaviour at the boundary before adding new tests around it.
- Time pressure forces triage. You rarely get to test every domain boundary. Experienced testers rank cross-variable constraints by risk — financial, regulatory, or safety impact — and apply domain analysis fully only to the highest-risk combinations. A fast risk conversation with the product owner beats exhaustive low-value testing every time.
5 When to Use It — and When Not To
✓ Use it when
- The spec contains any "if X then Y must be" language referencing two separate input fields
- A field's valid range is listed as "depends on the value of [another field]" in requirements, acceptance criteria, or a data dictionary
- Integration tests are failing at combinations that unit tests pass — this is the classic signature of an untested domain boundary
- You are testing financial, insurance, or government-benefit rules in NZ where regulatory constraints commonly tie eligibility criteria across multiple variables
- A previous defect was caused by two inputs that were each individually valid but invalid in combination — the defect history is telling you a domain boundary was missed
✗ Skip it when
- Inputs are genuinely independent — adding a domain analysis layer where no cross-variable constraint exists wastes time without reducing risk
- You are doing a quick smoke test or regression check where the goal is confidence, not exhaustive boundary coverage
- The system has three or more interacting variables with complex non-linear constraints — at that point, model-based testing or combinatorial tools are more tractable than manual domain analysis
- The constraint is already covered by a unit test at the service layer — avoid duplicating domain boundary tests that are already reliably caught lower in the stack
- Budget and time are extremely limited and the cross-variable constraint is low-risk or already covered by an existing contract test
Context guide
How the right level of domain analysis effort changes based on project context.
| Context | Priority | Why |
|---|---|---|
| Revenue NZ or Benefits NZ benefits forms with cross-field eligibility rules | Essential | NZ social security and tax legislation buries cross-variable constraints in policy PDFs and secondary regulations. A cross-field boundary missed here risks approving ineligible claims or blocking entitled applicants — both are compliance failures with real financial and reputational consequences. |
| Financial calculators with loan, insurance, or investment constraints (e.g. Harbour Bank, Pacific Bank) | Essential | Lending policies routinely tie valid term ranges to loan amount brackets. A cross-variable defect here can approve credit outside policy, creating regulatory and credit-risk exposure. Domain analysis at the boundary of each cross-field rule is non-negotiable before release. |
| TransitNZ or LandNZ portals with vehicle, property, or land-title rules | High use | Vehicle age, engine capacity, or land area often interact with fee tiers or inspection requirements. Domain analysis should cover the highest-risk cross-field constraint per release; full coverage of all constraints is ideal but may need to be risk-ranked. |
| Internal tooling or admin dashboards with low regulatory exposure | Medium | Cross-variable constraints still exist but the impact of a boundary defect is limited to internal users rather than citizens or customers. Apply domain analysis to any constraint explicitly documented in requirements; skip undiscovered constraints unless a defect report surfaces them. |
| Smoke or confidence regression — pre-release sanity checks | Low | The goal here is rapid confidence, not exhaustive boundary coverage. Run only the cross-boundary on/off pairs that have previously caused defects; skip full domain analysis until a dedicated regression cycle. |
| Exploratory testing sprint on a newly inherited legacy system (e.g. CoverNZ or HealthNZ codebase) | High use | Legacy systems accumulate undocumented cross-variable constraints over time. Domain analysis in discovery mode — scanning for "if X then Y" language in legacy docs and reverse-engineering the actual boundary by probing the live system — is the fastest way to surface hidden rules before they cause production incidents. |
Trade-offs
What you gain and what you give up when you choose domain analysis.
| Advantage | Disadvantage | Use instead when… |
|---|---|---|
| Finds defects that single-variable EP/BVA structurally cannot — the combination on/off the cross-variable boundary is only generated by choosing two values together deliberately. | Requires a constraint-discovery pass before test design — time you may not have on short sprints. If cross-variable constraints are not documented, you must interview domain experts to find them. | Fields are genuinely independent and no cross-field rule exists — run BVA on each field separately. Adding domain analysis without a real constraint wastes test cycles. |
| Produces precisely named, high-signal test cases (on-point $9,999/term 5; off-point $9,999/term 6) that are immediately actionable when a defect is found — developers can reproduce in seconds. | Test case count grows with the number of constraints — a form with five cross-field rules generates multiple on/off pairs per rule. Without triage, this can balloon scope on large legacy systems. | Three or more variables interact with non-linear constraints — switch to model-based testing or a combinatorial tool; manual domain analysis becomes intractable above two-variable interactions. |
| Acts as a specification quality check — any constraint you discover by questioning rather than reading the spec reveals a documentation gap. Documenting it improves the spec for the whole team. | The on/off precision depends on knowing the implementation's arithmetic type (integer vs. floating-point). If you do not clarify this with the developer first, you may design test values that miss the real boundary by a rounding unit. | The cross-field constraint is already fully covered by a reliable contract or integration test at the service layer — avoid duplicating a test that another layer already owns reliably. |
| Scales well in risk-triage mode — ranking constraints by regulatory or financial impact lets you apply full domain analysis only where it matters most, keeping test effort proportionate. | Domain analysis is an advanced technique. Junior testers unfamiliar with the on/off/in/out vocabulary or the concept of boundary regions in multi-dimensional space need coaching before they can apply it correctly. | Running a fast smoke or regression check before an urgent hotfix — the goal is confidence, not coverage; run only previously documented cross-boundary pairs rather than a full domain analysis pass. |
Enterprise reality
How Domain Analysis changes at 200–300-developer scale in NZ enterprise — where undocumented cross-variable constraints, regulatory exposure, and cross-squad ownership turn a technique into a discipline.
- What gets automated: At scale, constraint-discovery is the bottleneck — not test execution. Organisations like CloudBooks and KiwiFirst Bank feed domain models into property-based testing frameworks (Hypothesis in Python, fast-check in TypeScript) that generate on/off combinations automatically from declared constraints. Junior testers stop hand-crafting boundary pairs; they maintain the constraint catalogue and the tooling derives the test points. The manual skill that gets automated first is value selection; the skill that never gets automated is reading a policy PDF and recognising that “if salary exceeds $X then secondary source is mandatory” is a domain boundary at all.
- Governance and compliance: Under the Privacy Act 2020 and the NZ Information Security Manual (NZISM), government agencies and regulated entities must demonstrate that cross-field eligibility logic is tested before go-live — not just asserted. At Revenue NZ and Benefits NZ, domain analysis test evidence is attached to change-advisory-board requests. A cross-variable constraint that reaches production untested is a compliance gap, not just a quality gap. PCI DSS similarly requires documented test coverage of any rule that governs which cardholder data combinations trigger specific processing paths.
- Tooling at volume: At 200+ developer scale, domain constraints live in multiple places simultaneously — OpenAPI specs, JSON Schema, database CHECK constraints, and Drools or Camunda business-rule engines. Test teams at TechServNZ and HealthNZ use Pact (contract testing) to assert cross-field constraints at the API layer automatically, and schema-validation tools (Spectral, Schemathesis) to fuzz-test boundary combinations against live endpoints. The tester’s job shifts from designing test data to writing constraint declarations that the toolchain exercises continuously in CI.
- Cross-squad coordination: In a platform split across 10+ squads, a cross-variable constraint often spans a squad boundary — one squad owns the income field, another owns the secondary-source field, and neither owns the rule that ties them together. At Harbour Bank, missing domain boundary ownership has produced production incidents where a squad released an independently-tested change that silently shifted where a cross-field rule was enforced. The fix is a shared constraint registry (a living doc or ADR) that names the owning squad for every cross-variable rule, reviewed in architecture forums each quarter. Without it, domain analysis is done correctly in isolation and fails at integration.
◆ What I would do
Professional judgment — when to reach for domain analysis, when to skip it, and what to watch for.
Testing an updated Revenue NZ myIR income-reporting form. A newly added business rule in the spec footnotes states: "If total income declared exceeds $180,000, the secondary income source field becomes mandatory." The developers have unit-tested each field independently and are confident the form is ready for UAT.
Run domain analysis immediately before UAT, not after. I would design four cross-boundary test cases: income $180,001 with secondary source blank (should be rejected — off-point); income $180,001 with secondary source filled (should be accepted — on-point); income $180,000 with secondary source blank (should be accepted — threshold on-point, rule does not apply at exactly $180,000 unless the boundary is inclusive); income $179,999 with secondary source blank (should be accepted — clearly below threshold). I would confirm the inclusive/exclusive wording with the developer before finalising the on-point value. None of these cases exist in the unit test suite, and the most likely defect — the boundary being implemented as > rather than ≥ or vice versa — is only visible at the on-point.
A TransitNZ licensing portal update introduces the rule: "Vehicles over 20 years old with engine capacity above 3,000 cc require a special emissions inspection." The team is under sprint pressure and the test lead suggests only running BVA on the vehicle age field and the engine capacity field separately.
Push back on the single-variable approach and add a minimum viable domain analysis set: six cross-boundary cases targeting the corner of the rule (age 21 and capacity 3,001 — inspection required; age 20 and capacity 3,001 — no inspection required; age 21 and capacity 3,000 — no inspection required). I would also test the corner itself: age 21 and capacity 3,001. Under time pressure, these six cases replace a full analysis pass; they cover the two boundary segments and the corner that is highest risk. I would note in the test report that the individual axis boundaries (age 1/30, capacity 100/6,000) are lower priority than the cross-variable corner, because the constraint only fires at the intersection.
During a sprint review of an CoverNZ online levy calculator, a domain expert mentions in passing that "the standard levy rate applies for hours worked between 1 and 40, but earners who declare over 40 hours must also declare their employment category or the rate cannot be calculated." This constraint does not appear anywhere in the user stories or acceptance criteria.
Treat this as a specification defect first — raise it as a documentation gap and get it written into the acceptance criteria before the sprint ends, so the developer and next tester can see it. Then design domain analysis test cases: 40 hours, employment category blank (should be accepted — on-point, rule does not yet apply); 41 hours, employment category blank (should be rejected — off-point); 41 hours, employment category filled (should be accepted — confirms the constraint is satisfied); 20 hours, employment category blank (in-point — confirms normal behaviour). I would not delay design waiting for formal spec update; I would document my test intent in the test management tool against the relevant ticket and request the spec update in parallel.
The bottom line: Any time a specification clause names two input fields in the same sentence, you are looking at a domain boundary — and no amount of per-field BVA will ever test it. The senior discipline is spending five minutes scanning for these clauses before designing a single test case.
6 Best Practices
- ✓ Do a constraint-scan pass before designing any tests. Read the spec end to end looking only for cross-variable dependencies — words like "if", "when", "only if", "provided that", "subject to". List every one before choosing test values.
- ✓ Draw the constraint region in two-variable space before testing. Sketch amount vs. term on a grid, mark the forbidden zone, and identify the corner points. This takes five minutes and immediately surfaces the on/off test values you need.
- ✓ Test corner points first. Corners of the constraint region are at the intersection of two boundaries simultaneously — they are the highest-risk points and the first to cut when time is short.
- ✓ Confirm the boundary is inclusive or exclusive before naming your on-point. "Under $10,000" (exclusive) and "up to $10,000" (inclusive) produce different on-points. Get this wrong and your test design is inverted. Check the spec wording precisely, then confirm with a developer.
- ✓ Ask about the implementation's arithmetic type before finalising boundary values. Integer, decimal, or floating-point each produce different effective precision at the boundary. The on-point must be the implementation's nearest representable value, not just the spec's idealised number.
- ✓ Test the boundary from both sides of the dependent variable, not just one. For "loans under $10,000 only available for terms 1–5 years", test at $9,999 (term 5 and term 6) AND at $10,000 (term 6). The threshold on the amount axis is itself a domain boundary.
- ✓ Name tests explicitly — not just "boundary test" but "on-point: amount $9,999 term 5". Precise naming makes failures immediately actionable and makes domain analysis visible to developers and product owners in your test report.
- ✓ Pair domain analysis with exploratory testing around the boundary. After designing structured on/off points, spend 10–15 minutes exploring freely near the constraint. Structured design catches the points you can reason about; exploration catches the points you could not predict.
- ✓ Document discovered constraints back into the spec or acceptance criteria. If you had to discover a cross-variable constraint through questioning, it means the spec was incomplete. Add the constraint explicitly so the next tester — or the next developer — does not have to rediscover it.
- ✓ Re-run domain boundary tests after every release that touches either variable. A change to the amount field logic may silently shift where the cross-variable constraint is enforced. Boundary tests are high-value regression assets.
7 Common Misconceptions
❌ Myth: If I've tested every field with BVA, domain analysis is redundant.
Reality: BVA on individual fields tests each variable in isolation, usually pairing the boundary value of one field with a "normal" value for the other. This never constructs the specific combinations that land on a cross-variable boundary. The loan amount boundary at $9,999 and the term boundary at 5 years are each tested individually by BVA — but BVA never tests $9,999 paired with 6 years, which is the only combination that violates the cross-variable constraint. The two techniques are not redundant: BVA covers single-axis boundaries, domain analysis covers the lines and regions that emerge from the interaction of multiple inputs.
❌ Myth: On-point means the value that is just barely valid.
Reality: The on-point is the value exactly on the boundary — which may be valid or invalid depending on whether the boundary is inclusive or exclusive. For "age >= 18", the on-point is 18 and it is valid. For "amount < $10,000", the on-point is $10,000 and it is invalid (the constraint does not apply at $10,000 — it applies strictly below it). Confusing "on-point" with "just barely valid" is the most common domain analysis labelling error in ISTQB exams and in real test documentation.
❌ Myth: Domain analysis only applies to numeric inputs.
Reality: The technique applies to any input space where a constraint ties the valid values of one field to the value of another. A dropdown for account type combined with a text field for company registration number has a domain boundary: "company registration required if account type is Business". A date field for departure date combined with a date field for return date has a constraint: "return must be after departure". Domain analysis applies — the fact that neither field is a number does not change the need to test at the constraint boundary, not just each field independently.
8 Now You Try
Three graded exercises — spot, fix, then build. Write your answer, run it for AI feedback, then compare to the model answer.
A Work and Income NZ benefit-estimate tool has two inputs: weekly income ($0–$2,000) and hours worked per week (0–60). A spec footnote says: “An applicant declaring income above $800 per week must also declare 30 or more hours worked.” Identify the cross-variable boundary this creates and explain why testing each field on its own would miss it.
Show model answer
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.
A tester analysed an CoverNZ levy field with the constraint “cover applies for ages 18 to 65 inclusive” and labelled the points below. Several labels and expected results are wrong. Correct them, using on-point, off-point, in-point, out-point.
Age 18 — off-point — Rejected
Age 17 — on-point — Accepted
Age 40 — out-point — Accepted
Age 90 — in-point — Rejected
Rewrite with correct point type and result for each:
Show model answer
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.
A KiwiSaver first-home withdrawal tool has two inputs: amount withdrawn and balance retained. Rule: “You must leave at least $1,000 in your account after withdrawal.” So amount ≤ (balance − $1,000). For a member with a $50,000 balance, design domain-analysis test points (on, off, in, out) that test the cross-variable withdrawal boundary, with expected results.
Show model answer
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".
Why teams fail here
- Treating multi-field test plans as a checklist of individual fields — BVA done per field is logged as "boundary testing complete" even when cross-variable constraints exist.
- Not reading the full specification for inter-field language — constraint clauses like "only when", "subject to", or "provided that [other field]" are skipped because testers are reading for field-level rules, not relationship rules.
- Trusting unit tests to cover domain boundaries — a developer unit-testing each validator in isolation never constructs the specific pair of values that sits on a cross-variable constraint line, so the integration-level boundary goes untested until production.
- Discovering constraints too late — finding an undocumented inter-variable rule during execution rather than during analysis means it surfaces as a late defect or, worse, a production incident instead of a planned test case.
Key takeaway
Any specification clause that mentions two input fields in the same sentence is a domain boundary — and it will never be tested by checking each field on its own.
How this has changed
The field moved. Here is how Domain Analysis evolved from its origins to current practice.
Domain expertise in software testing is tacit knowledge held by experienced practitioners. There is no named technique for analysing the business domain to derive test cases. Testers learn by sitting with SMEs and absorbing domain rules informally.
Boris Beizer and Cem Kaner codify domain analysis as a test design technique in testing literature. The idea: before designing test cases, model the business domain — understand the data, rules, workflows, and user types — to derive tests that reflect reality rather than just the specification.
Domain-driven design (DDD) from the development community gives testers a vocabulary for domain modelling — bounded contexts, entities, aggregates, ubiquitous language. BDD/ATDD formalises the collaboration between domain experts and testers in defining expected behaviour.
Event storming (Alberto Brandolini) becomes a popular domain modelling technique for distributed systems. Testers participate in event storming sessions to understand system flows and derive integration test scenarios from domain events.
AI tools can extract domain concepts from specifications and suggest domain-specific test scenarios — a form of automated domain analysis. Human testers still need deep domain expertise to judge whether AI-suggested scenarios reflect real business risk.
Interview Questions
What NZ hiring managers ask about Domain Analysis — and what strong answers look like.
How does domain analysis inform your test design on a new project in an unfamiliar domain?
Strong answer: I start by interviewing domain experts — what are the key entities, rules, and workflows? What are the edge cases they care about that the spec does not mention? I ask about past failures: what has gone wrong before? I look for the domain vocabulary — understanding that "settlement date" in banking is different from "transaction date" changes my test design significantly. I then build a domain model (even informally) and use it to derive test scenarios that reflect real-world usage rather than just spec coverage. Tests derived from domain knowledge tend to find bugs that requirements-based tests miss.
Mid/Senior
You are assigned to test a new KiwiSaver management feature. What domain knowledge do you need before writing test cases?
Strong answer: I need to understand: the contribution rules (employee rates 3-10%, employer minimum 3%, government contributions); the fund types and transfer rules (when can members switch funds?); the withdrawal rules (first home withdrawal, serious illness, financial hardship, 65+ withdrawal conditions); the tax treatment (PIR rates, PIE tax); and the reporting obligations to Revenue NZ. I also need to know the downstream systems: the Revenue NZ integration for contribution recording, the Registry (Computershare or Link) for unit pricing, and the bank integration for contributions and withdrawals. Without this, I cannot distinguish a correct calculation from a wrong one.
Senior/Lead
Self-Check
Click each question to reveal the answer.
Q1: What does domain analysis add beyond boundary value analysis?
BVA tests the edges of one variable at a time, treating inputs as independent. Domain analysis tests boundaries that exist only because two or more variables interact — a line or curve in the combined input space — by choosing the variables together so the combination lands on, just inside, and just outside the constraint.
Q2: Define on-point, off-point, in-point, and out-point.
On-point: the value exactly on the boundary (always tested). Off-point: the closest value on the other side of the boundary (always tested). In-point: any value well inside the valid partition. Out-point: any value well outside the valid partition. On and off points carry the most risk because bugs cluster at the edge.
Q3: For an inclusive boundary “age ≥ 18” with integer values, what are the on-point and off-point, and what results do they expect?
On-point is 18 (Accepted — the boundary itself is valid because it is inclusive). Off-point is 17 (Rejected — the nearest value on the invalid side). Getting these swapped, or mishandling the inclusive/exclusive wording, is the most common labelling error.
Q4: Why are the corner points of a linear constraint region the highest-risk to test?
A corner sits at the intersection of two constraints at once, so it is where two boundaries, and any rounding or off-by-one errors in either, can combine. Domain analysis tests each corner of the boundary region plus an on-point and off-point on each segment.
Q5: How do you spot, in a specification or user story, that domain analysis is needed?
Look for language that ties two inputs together — “if X and Y then…”, “available only when…”, or a field whose valid range depends on another field. Constraints are often buried in footnotes, data dictionaries, or acceptance criteria. Any such cross-reference between two inputs is a domain boundary to test.
Q6: Your team is testing a new TransitNZ vehicle licensing portal. One screen accepts vehicle age (1–30 years) and engine capacity (100–6,000 cc). A business rule states: “Vehicles over 20 years old with engine capacity above 3,000 cc require a special emissions inspection.” How do you approach testing this, and why would standard BVA on each field be insufficient?
This is a cross-variable constraint: the obligation to inspect depends on both age and capacity together. Standard BVA would test age at 20/21 and capacity at 3,000/3,001 independently, but would never pair “age 21, capacity 3,001” as a deliberate combination. Domain analysis requires you to identify the boundary region (age > 20 AND capacity > 3,000), then design on-point, off-point, in-point, and out-point tests that choose both values together — for example, age 21/capacity 3,001 (on-point, inspection required), age 20/capacity 3,001 (off-point, inspection not required), and age 21/capacity 3,000 (off-point on the other axis). The corner at age 21, capacity 3,001 is the highest-risk point and must be tested first.
Q7: What is the key difference between domain analysis and decision table testing, and when would you choose one over the other?
Decision table testing models combinations of conditions that are each true or false (boolean), capturing all rule permutations in a table. Domain analysis focuses on the precise numeric or ordered boundary between valid and invalid values in a multi-dimensional input space, and prescribes specific on/off/in/out test points around that boundary. Choose decision tables when constraints are expressed as discrete logical conditions with distinct actions per combination. Choose domain analysis when the constraint involves a threshold or range that depends on another variable — for example, when the valid term for a loan changes as the amount crosses a dollar boundary. In practice, both techniques can complement each other: decision tables to identify which combination of conditions applies, domain analysis to determine the exact boundary values to test within each cell.
Q8: When should you NOT apply domain analysis, even if two input fields are present on the same screen?
Skip domain analysis when the two fields are genuinely independent — no specification rule, business constraint, or data dictionary entry links the valid range of one to the value of the other. Applying domain analysis where no cross-variable constraint exists produces unnecessary test cases and wastes time without reducing risk. Also skip it when the constraint is already fully covered by a unit or contract test at the service layer, when you are running a quick smoke or regression check focused on confidence rather than coverage, or when the system has three or more interacting variables with non-linear constraints — at that point, model-based testing or a combinatorial tool is more tractable. For example, an Benefits NZ benefits portal might have a name field and a date-of-birth field on the same screen; if no business rule links the two, there is no domain boundary to analyse and BVA on each field alone is correct.
Q9: A developer tells you: “I've already unit-tested all the individual validation rules for our Revenue NZ income-reporting form, so we don't need any extra cross-field tests.” What is wrong with this reasoning and how do you respond?
Unit tests that validate each rule in isolation confirm that each validator works when called with a controlled input — but they do not test the interaction between two validators when both fire on the same request. A cross-variable constraint such as “if reported income exceeds $180,000, the secondary income source field becomes mandatory” only manifests when both the income value and the secondary-source field are evaluated together against the combined rule. The developer's unit test for the income field and the unit test for the secondary-source field can both pass while the integration path that enforces the cross-field rule is never exercised. You respond by showing the specific combination (e.g., income $180,001 with secondary source blank) that no existing unit test constructs, and explaining that domain analysis tests are integration-level assertions about the rule that emerges from the interaction — a different layer from the unit tests, not a duplication of them.
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.
Senior engineer insight
When I started applying domain analysis properly, the shift that changed everything was realising I needed to read specs differently: stop scanning for what each field does and start hunting for any sentence that mentions two fields in the same clause. That single habit surfaces more cross-variable constraints in ten minutes than a full day of independent-field test design. The second shift: treat every constraint you discover by asking a domain expert as a specification defect — it was missing from the written requirements — and document it there and then.
The most common mistake: completing BVA on every field, writing "boundary tests done" in the test plan, and never once putting two boundary values in the same request. The cross-variable boundary is invisible to that process — and that is exactly where the production defects hide.
From the field
On a Benefits NZ benefits portal, we were testing a weekly-hours and income-threshold rule — the kind buried three levels deep in NZ social security policy. Every individual field test passed. The developers were confident. We shipped to UAT and an Benefits NZ domain expert raised a defect within 20 minutes: a combination of just-under-threshold income with just-above-threshold hours was being accepted when it should have been blocked. The constraint existed only in the interaction between the two fields; it wasn’t in the user story, it was in a policy PDF nobody had linked to the ticket. The lesson that generalises: in any domain with layered legislation — NZ welfare, Revenue NZ tax, LandNZ land transactions — the most dangerous constraints are the ones that live between fields, not on them, and the only way to find them is a structured conversation with a domain expert before you write a single test case.