Library Automation/ Black Box/ Boundary Value Analysis

20 min read · 9 self-checks · Updated June 2026

Black Box · Specification-Based

Boundary Value Analysis

Test the edges of equivalence partitions. Bugs cluster at boundaries — off-by-one errors, fencepost mistakes, and incorrect comparisons (< vs ≤) almost always appear at the exact limit.

Junior Senior ISTQB CTFL v4.0 — 4.2.2

1 The Hook

An Harbour Bank online savings product offers a bonus interest rate when the monthly balance stays at $1,000 or above. A team builds the feature and tests it with a tidy round figure: $5,000 in the account, bonus applied, looks great. Ship it.

A month later a customer complains. They held exactly $1,000 all month and got no bonus. The developer had coded the check as balance > 1000 instead of balance >= 1000 — an off-by-one slip. Every customer sitting on precisely the threshold was quietly short-changed. The test with $5,000 could never have caught it, because $5,000 is nowhere near the edge where the bug lives.

This is the pattern behind a huge share of real defects: the logic is right in the middle of the range and wrong at the exact limit. A value picked from the comfortable middle of a partition tells you nothing about the boundary. The bug was always going to be at $1,000, $999, or $1,001 — and those were the three values nobody tested.

💡
Key Takeaway

Boundary Value Analysis means testing the values right at and just outside the edges of a valid range — not the comfortable middle — because off-by-one coding errors (< vs ≤) only produce wrong behaviour at the exact limit. Use it whenever a spec defines an ordered range with a minimum or maximum: numbers, dates, string lengths, file sizes, or any ordered domain. The mistake most testers make is testing the boundary itself but skipping the "just outside" value — yet that adjacent value is the only one that can catch a silent accept-when-it-should-reject bug that bypasses UI validation via API or data import.

💬
Senior Engineer Insight

The failure mode nobody warns you about: your BVA test cases are perfectly correct, and they still miss the bug. I have seen this in NZ financial systems repeatedly. You design a set for a field accepting whole-number percentages 3 to 10, you test 2, 3, 10, and 11 — textbook. Then you discover the database column is a DECIMAL(5,2), so 2.5 is a valid value that slips straight through both boundaries and corrupts the downstream calculation. Before you write a single boundary value, ask the developer one question: what is the actual data type? Integer, float, decimal, string coerced at runtime? The data type determines where the real boundaries sit. In two decades of reviewing test suites across banking and government projects here, the "I tested the UI integer field but the API accepts floats" gap is the most common reason a technically correct BVA set still ships a defect.

2 The Rule

Defects cluster at the edges of a range, not in the middle — so for every boundary, test the value on the boundary and the value just across it (2-value), or the value below, on, and above it (3-value).

3 The Analogy

Analogy

The height sign at a theme-park ride.

A ride at Rainbow's End has a sign: "You must be 120 cm to ride." The interesting arguments never happen with a kid who is obviously tall or obviously tiny — they happen with the child measured at exactly 120 cm, or 119, or 121. That is where the rule is tested in the real world: right at the line. Does "120 cm to ride" mean 120 gets on, or 120 is too short? The sign's wording (the spec) decides, and that exact point is where staff get it wrong.

Boundary value analysis is standing at the height sign and measuring the three kids right around the line, instead of waving through the obviously-tall ones. The edge is where the rule either holds or breaks.

Common Mistake vs What Works

✗ Common mistake

Testing only a mid-range value and the obvious out-of-range values — for a field accepting 1–100, you test 0 (invalid), 50 (valid), and 101 (invalid) and call it done. No test ever touches 1 or 100. The bug living at the exact boundary is invisible.

✓ What actually works

Test the boundary itself and the value on each side: 0 (invalid), 1 (valid lower bound), 2 (valid), 99 (valid), 100 (valid upper bound), 101 (invalid). Six tests instead of three — and if the developer wrote > instead of ≥, tests at 1 and 100 are the only ones that will catch it.

What it is

Boundary Value Analysis (BVA) is an extension of Equivalence Partitioning. Once you have your partitions, instead of picking a value in the middle, you test the values at and around the boundary between partitions.

Why boundaries? Developers tend to make off-by-one errors. A spec that says "accept 18–65" might be coded as > 18 instead of >= 18 — a bug that only appears at exactly 18.

2-value BVA (ISTQB standard)

For each boundary, test two values: the boundary itself, and the value just beyond it.

  • For a range 18–65: test 18 (in), 17 (out), 65 (in), 66 (out).

3-value BVA (robust)

Test three values at each boundary: the value just below, the boundary itself, and the value just above.

  • At lower boundary (18): test 17, 18, 19
  • At upper boundary (65): test 64, 65, 66

3-value BVA gives stronger coverage but doubles your test count. Use it when the boundary logic is critical or complex.

Real-world NZ Example: KiwiSaver Eligibility

In New Zealand, to join KiwiSaver independently (without legal guardian consent), you must be 18. You can begin withdrawing your savings at 65. Using 2-value BVA, your test cases are:

  • 17: Invalid (just below independent age)
  • 18: Valid (minimum independent age)
  • 64: Valid (just below withdrawal age)
  • 65: Valid (minimum withdrawal age)
  • 66: Valid (above withdrawal age — still eligible to contribute, but state contribution stops)

Worked example

Password length field: minimum 8 characters, maximum 20 characters.

Password length — 2-value BVA test cases
ValueLengthBoundary?Expected
"passwor"7Just below minRejected
"password"8Minimum boundaryAccepted
"12345678901234567890"20Maximum boundaryAccepted
"123456789012345678901"21Just above maxRejected

Combined with EP: BVA gives you boundary tests; EP gives you mid-range tests. Together they cover: one value per valid partition (EP), the boundaries of each partition (BVA), and one representative invalid value per invalid partition (EP). This is standard practice at junior level and above.

ISTQB mapping

ISTQB CTFL v4.0 reference
Syllabus refTopicLevel
4.2.2Boundary Value AnalysisCTFL Foundation
FL-4.2.2 K3Apply 2-value BVA to derive test casesFoundation LO
FL-4.2.2 K3Apply 3-value BVA to derive test casesFoundation LO

Common mistakes

  • Forgetting the "just outside" value — testing only the boundary itself misses off-by-one errors.
  • Mixing BVA and EP carelessly — BVA tests the boundary; EP tests the middle. Don't conflate them.
  • Non-numeric boundaries — BVA applies to anything ordered: dates, string lengths, list sizes, file sizes, priority levels.
  • Inclusive vs exclusive confusion — always check whether the spec says "<" or "≤" before choosing your boundary values.

4 Industry Reality

🏭 What you actually encounter on the job
  • Requirements rarely name the boundary type. Specs written by business analysts say things like "must be at least 18" without clarifying whether 18 itself is valid. You will chase down the developer, a legal document, or the product owner to settle inclusive vs exclusive — and the answer sometimes changes late in the sprint.
  • Legacy systems have undocumented implicit boundaries. A payment-processing system at an NZ bank might silently cap transaction amounts at $99,999.99 — not because the spec says so, but because a database column was defined as DECIMAL(7,2) fifteen years ago. Senior testers probe these limits even when they are not in the requirements.
  • Time pressure turns BVA into "test the happy path near the boundary." When a sprint is overloaded, junior testers test 3, 10, and maybe 2 — they skip 11 because "surely the UI blocks that." It doesn't. The just-outside value is exactly what QA exists to test.
  • Non-numeric boundaries catch everyone out. Date boundaries — Revenue NZ filing windows, CoverNZ claim deadlines, KiwiSaver lock-in periods — are where off-by-one bugs are hardest to spot manually. A test that passes on 30 June fails on 1 July. Testers who learn BVA on number fields often forget to apply it to date comparisons.
  • The "just outside" value is the most argued test case. Developers regularly push back: "no real user would enter 10,001." That is irrelevant — the system has a defined rule at 10,000, and every boundary has a failure mode waiting for an adversarial input, an integration that passes unexpected data, or a migration that shifts values by one.

Senior engineer insight

The scenario that changed how I use BVA happened on an Revenue NZ late-filing penalty feature. We had a textbook 2-value set — $47,999, $48,000, $48,001 — all passing. Six months later a batch payroll import silently filed returns at exactly $48,000.00 and the penalty fired incorrectly because a downstream rounding step converted the database DECIMAL(10,2) to a float, pushing the value to $47,999.9997 — just inside the safe partition. The boundary test passed at the API layer but the real defect lived one step further down in the pipeline. After that I started tracing every boundary through the full data path: input → validation → storage → calculation → output. The edge that matters is the one closest to the business rule, not the one closest to the form field.

The most common mistake I see from graduates: they test the boundary on the UI and stop there — never realising the API, import job, or calculation layer is operating on a different data type at a slightly different boundary.

From the field

We were testing an CoverNZ weekly compensation calculator that applied a levy band change at the $104,000 annual earnings threshold — a real CoverNZ boundary that determines which employer levy rate applies. The team had tested $103,999 and $104,001 through the UI form and both passed. Three months after go-live, a batch payroll run for a client with exactly $104,000 in earnings fired the wrong levy rate, costing the client $340 in incorrect deductions. The root cause: the UI rounded the entered value to two decimal places before submission, but the batch import sent the raw figure as a float, hitting a floating-point representation just below $104,000.00 — landing in the wrong partition. From that point on, every CoverNZ and Revenue NZ threshold test in our test plan explicitly lists both the UI path and the API/batch path as separate test cases, with the data type confirmed at each layer before we sign off coverage.

5 When to Use It — and When Not To

⚡ Decision guide

✓ Use it when

  • The field has a clearly defined numeric, date, or ordered range (minimum, maximum, or both)
  • The spec uses comparison language: "at least", "no more than", "between X and Y", "minimum", "maximum"
  • The boundary represents a business rule with consequences — KiwiSaver eligibility, TransitNZ vehicle limits, Revenue NZ thresholds, age gates
  • You need to catch off-by-one coding errors (< vs ≤) in numeric or date comparisons
  • You are already doing Equivalence Partitioning — BVA is always the natural next step once partitions are defined

✗ Skip it when

  • There is no ordered range — boolean flags, free-text fields without length limits, unordered enums (e.g. dropdown of NZ regions) have no meaningful boundary to test
  • The input is already fully validated by a UI control that makes out-of-range values physically impossible to enter (and you have confirmed there is no API bypass)
  • Multiple interacting variables mean the boundary shifts dynamically — use Decision Table or pairwise testing instead
  • You are writing smoke tests or a quick sanity check — BVA is a coverage technique, not a fast-path validator
  • The range has hundreds of valid discrete values and the business risk is low — a single mid-partition EP value is enough

Context guide

How the right level of Boundary Value Analysis effort changes based on project context.

Context Priority Why
Regulated government or financial system (Revenue NZ, CoverNZ, Benefits NZ, RBNZ) Essential An off-by-one at thresholds like the $48,000 Revenue NZ penalty cutoff or CoverNZ’s $104,000 annual-earnings levy band has direct legal and financial consequences; 3-value BVA at the API layer is non-negotiable.
Enterprise banking or insurance product (KiwiSaver, home-loan LVR, insurance claim limits) High Numeric boundaries (contribution rates 3–10%, LVR caps, date windows for policy inception) appear in almost every flow; boundary bugs here trigger complaints, refunds, and audit findings.
Legacy system migration (replatforming a payroll, billing, or fee-calculation engine) High Column-type changes (DECIMAL(7,2) to FLOAT) silently shift implicit boundaries; run BVA against the old and new systems at every documented threshold and compare outputs, not just UI behaviour.
Agile sprint — story with a numeric or date range acceptance criterion Medium Add the two just-outside values to the Definition of Done for any story with a stated minimum or maximum; 2-value BVA fits within sprint cadence, but skip 3-value unless the boundary is business-critical.
Early-stage startup with frequently changing business rules Medium Apply 2-value BVA to validated, stable boundaries (e.g. a field length limit or age gate); skip exhaustive BVA on thresholds that are still changing — invest the time in exploratory testing and risk discovery instead.
Low-risk UI-only feature with no API exposure (search filters, display settings, pagination) Low When the boundary is purely cosmetic (e.g. showing 10–100 results per page) and there is no downstream calculation or data-path bypass, a single EP mid-range value is usually enough — spend saved time on riskier flows.

Trade-offs

What you gain and what you give up when you choose Boundary Value Analysis.

Advantage Disadvantage Use instead when…
Directly targets the most common coding defect — off-by-one errors at < vs ≤ comparisons Only useful when the spec defines an ordered range; useless on unordered domains like dropdown lists or boolean flags The field accepts an unordered set of discrete values — use Equivalence Partitioning alone
Small, predictable test count — 2-value BVA produces exactly four tests per simple range boundary Count multiplies quickly when boundaries interact — a form with five numeric fields can require 20+ boundary cases before combinatorial explosion sets in Multiple interacting boundaries define business rules — use Decision Table or pairwise testing to manage the combinations
Works on any ordered domain — numbers, dates, string lengths, file sizes, priority levels, queue depths Reveals where the defect is (the boundary) but not what caused it — you still need investigation to trace data-type mismatches, rounding, or implicit conversions You need to understand why the system behaves wrongly at the boundary — use exploratory testing or session-based testing to investigate after BVA flags the defect
Low entry cost — once partitions exist (from EP), deriving boundary values is mechanical and teachable to junior testers Does not test inside the partition — a mid-range error, a wrong calculation, or incorrect business logic in the happy path is invisible to BVA You suspect errors in mid-range logic, not at the edges — pair with Equivalence Partitioning to cover both
High ROI on high-stakes NZ systems — Revenue NZ penalty thresholds, CoverNZ weekly compensation caps, KiwiSaver eligibility dates all have legal and financial consequences at the exact boundary Requires a clearly specified boundary — if the BA writes "roughly around $500" or "the system should handle reasonable ages," you cannot derive BVA values until the spec is tightened Requirements are intentionally vague or subject to change — use Risk-Based Testing to decide which boundaries to nail down first and raise spec ambiguities as defects

6 Best Practices

✓ What experienced testers do
  • Always confirm inclusive vs exclusive before deriving values. Read the spec word-for-word. "Greater than 18" and "18 or older" generate different boundary test values — the first means 18 should reject, the second means 18 should accept.
  • Run BVA at the API level, not just the UI. Front-end validation often prevents you entering 21 characters in a 20-char field, but the API endpoint may have no such guard. Test both surfaces.
  • Pair every BVA run with at least one EP mid-range value. Boundaries tell you the rule fires correctly at the edge; a mid-partition value confirms the happy path works. Logging one of each in your test case set is standard practice.
  • For date boundaries, name the exact calendar day — never just say "the day before". "31 March" is unambiguous; "one day before 1 April" leads to bugs in February in a leap year. Be precise in your test cases and test data.
  • Document why you chose each value. A test case that reads "value: 3499, expected: reject, reason: just below lower BVA boundary (range starts at 3500 inclusive)" is reviewable and defensible. "value: 3499, expected: reject" is not.
  • When requirements are vague about the boundary, test both interpretations and flag the ambiguity. Write one test case where 18 accepts and one where it rejects, mark both as "pending requirements clarification", and raise a defect against the spec — not just against the code.
  • Use 3-value BVA for high-risk or financial boundaries. Revenue NZ penalty thresholds, RBNZ capital ratios, CoverNZ levy tiers — wherever a one-unit error costs money or compliance, the extra "just inside" values are worth the effort.
  • Do not skip the just-outside invalid value because "the UI won't allow it." Data migrations, imports, API integrations, and automated scripts all bypass the UI. The boundary logic in the back end is what actually matters.
  • Combine with State Transition testing for session or workflow boundaries. If a KiwiSaver account switches state when the balance crosses a threshold, the boundary is both numeric (BVA) and a state trigger — test it with both lenses.
  • Review your boundary test cases against the actual implementation after a bug is found. When a boundary bug is raised, check whether your BVA set covered it. If it didn't, update your technique — the most common gap is testing the boundary on the wrong data type (integer vs float).

7 Common Misconceptions

❌ Myth: "BVA and Equivalence Partitioning are basically the same thing — just pick values near the edge."

Reality: They are complementary but distinct. EP selects one representative value from the middle of each partition to confirm the partition behaves correctly. BVA selects values at the boundary between partitions to catch the off-by-one errors EP cannot see. Using EP mid-values near a boundary does not constitute BVA — you must test the exact boundary value and the value just outside it.

❌ Myth: "BVA is only for number fields. Dates and strings are different."

Reality: BVA applies to any ordered domain. String length fields (min 8, max 20 characters) have numeric boundaries on their length. Date fields have calendar boundaries — an Revenue NZ filing window opening on 1 April 2025 has a just-before boundary of 31 March 2025 and a just-after of 2 April 2025. Month-length variation (28–31 days) and leap years make date boundaries especially prone to off-by-one bugs, so BVA is arguably more valuable on dates than on plain integers.

❌ Myth: "If the test passes at the boundary, I can skip the just-outside value — it's obviously going to fail."

Reality: The just-outside value tests a different logical branch. It is not there to confirm the obvious — it is there to catch cases where the system incorrectly accepts an out-of-range input, a far more dangerous failure than a false rejection. Systems that silently accept 10,001 when the limit is 10,000 can corrupt downstream calculations, trip compliance audits, or quietly short-change customers. The just-outside value must be tested and expected to fail.

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.

🔍 Exercise 1 of 3 — Spot: name the boundary values

A TransitNZ heavy-vehicle permit form accepts a gross vehicle mass from 3,500 kg to 44,000 kg (inclusive). Using 2-value BVA, list the boundary test values and the expected result (accept/reject) for each. Then state which values 3-value BVA would add.

Show model answer 
2-value BVA for the range 3,500–44,000 kg:
- 3,499 kg — Reject (just below lower boundary)
- 3,500 kg — Accept (lower boundary, inclusive)
- 44,000 kg — Accept (upper boundary, inclusive)
- 44,001 kg — Reject (just above upper boundary)

3-value BVA adds the value just inside each boundary:
- 3,501 kg — Accept (just above lower boundary)
- 43,999 kg — Accept (just below upper boundary)

The whole point is the inclusive boundaries: 3,500 and 44,000 must be ACCEPTED. The classic bug is coding > 3500 instead of >= 3500, which would wrongly reject a vehicle at exactly 3,500 kg.
🔧 Exercise 2 of 3 — Fix: repair a flawed BVA set

A tester wrote the BVA set below for a KiwiSaver contribution-rate field (whole percentages 3 to 10 inclusive). It is wrong: it tests middles instead of edges, misses a boundary, and gets one expected result wrong. Rewrite it as a correct 2-value BVA set.

Flawed set:
5 — Accept
3 — Reject
7 — Accept
11 — Reject

Rewrite as correct 2-value BVA:

Show model answer 
Correct 2-value BVA for rates 3–10 inclusive:
- 2 — Reject (just below lower boundary)
- 3 — Accept (lower boundary)
- 10 — Accept (upper boundary)
- 11 — Reject (just above upper boundary)

What was wrong with the original:
- Tested middles, not edges: 5 and 7 are mid-range values — that is equivalence partitioning, not BVA. BVA wants the values at and just outside the boundaries.
- Wrong expected result: 3 is the lower boundary and is valid, so it should ACCEPT, not reject.
- Missing boundary: nothing tested 2 (just below min) or 10 (the upper boundary itself). Only 11 was on the upper side.
🏗️ Exercise 3 of 3 — Build: a 3-value BVA set for a date field

An Revenue NZ tax-return portal accepts a return for the 2024–25 tax year: valid filing dates run from 1 April 2025 to 7 July 2025 (inclusive). Design a full 3-value BVA set of test dates with the expected result for each. Remember boundaries apply to dates, not just numbers.

Show model answer 
3-value BVA for the date range 1 Apr 2025 – 7 Jul 2025 inclusive:

Lower boundary (1 Apr 2025):
- 31 Mar 2025 — Reject (just below)
- 1 Apr 2025 — Accept (boundary, inclusive)
- 2 Apr 2025 — Accept (just above)

Upper boundary (7 Jul 2025):
- 6 Jul 2025 — Accept (just below)
- 7 Jul 2025 — Accept (boundary, inclusive)
- 8 Jul 2025 — Reject (just above)

Six test dates. The "just below" date at the lower edge is 31 March because March has 31 days — date boundaries are where off-by-one and month-length bugs hide. A senior would also flag that both boundary dates must be accepted (inclusive), and would test a leap-day or end-of-month edge if the range crossed one.

Why teams fail here

  • They test the boundary through the UI only and stop — not realising that payroll imports, API integrations, and bulk migrations bypass the UI entirely and hit the back-end rule directly, often with a different data type.
  • They test the boundary value itself but skip the just-outside value, assuming "the system will obviously reject it" — which is exactly the assumption that lets a silent accept-when-it-should-reject bug ship to production undetected.
  • They read "3% to 10%" in the spec and assume inclusive without confirming — then write expected results that are wrong because the developer read the same words and implemented exclusive. For KiwiSaver and Revenue NZ thresholds, the inclusive/exclusive question must be settled in writing before the first test runs.
  • They identify the obvious numeric boundary but miss the same boundary on a downstream field — for example, testing the Revenue NZ income threshold on the input form but never checking that the stored value in the database and the value read back by the penalty calculation engine are the same number, not a rounded or truncated copy.

How this has changed

The field moved. Here is how Boundary Value Analysis evolved from its origins to current practice.

1970s

BVA emerges from academic computer science as a formal partition testing technique. Glenford Myers documents it in "The Art of Software Testing" (1979). Used primarily by researchers and a small number of methodical practitioners.

1990s

ISTQB Foundation Level curriculum formalises BVA as a standard technique. It becomes a required topic in certification. Most practitioners learn it as a textbook exercise rather than a practical skill.

2000s

Agile adoption creates pressure to apply BVA quickly without ceremony. Practitioners learn to do informal BVA during story refinement, not as a separate documentation step. The technique stays the same; the timing moves earlier.

2010s

Test data generation tools begin automating BVA boundary identification from spec files and OpenAPI schemas. Teams start generating boundary test cases rather than hand-crafting them.

Now

AI-assisted tools (Copilot, purpose-built test generators) can propose boundary cases from natural language requirements. Human testers validate and curate rather than derive from scratch. The skill shifts from computation to judgement.

Prerequisites

Related techniques

Self-Check

Click each question to reveal the answer.

Q1: Why does a test value picked from the middle of a valid range rarely catch boundary bugs?

Boundary defects — off-by-one errors, < vs ≤ mistakes — only change behaviour at the exact limit. A mid-range value behaves identically whether the code says > or ≥, so it cannot expose the slip. You have to test at and around the edge.

Q2: For an inclusive range 8 to 20, what four values does 2-value BVA test, and what are the expected results?

7 (reject, just below min), 8 (accept, lower boundary), 20 (accept, upper boundary), 21 (reject, just above max). The two boundary values themselves must be accepted because the range is inclusive.

Q3: What two extra values does 3-value BVA add at each boundary, and when is it worth the cost?

It adds the value just inside each boundary (e.g. 9 just above the lower edge, 19 just below the upper edge), so each boundary is tested below, on, and above. Use it when the boundary logic is critical or complex; it roughly doubles the test count.

Q4: Does BVA apply only to numbers?

No — it applies to anything ordered: dates, string lengths, list sizes, file sizes, priority levels. A date field has boundaries (first and last valid date) just as a numeric range does, and month-length and leap-day edges make dates especially bug-prone.

Q5: Before choosing your boundary values, what must you check in the specification?

Whether each limit is inclusive or exclusive — "<" versus "≤". The wording decides whether the boundary value itself should be accepted or rejected, and getting that wrong means your expected results are wrong even if your values are right.

Q6: Your team is testing the Benefits NZ Jobseeker Support application portal. The portal rejects applications if the applicant’s declared weekly income exceeds $500. The product owner says “just check that $0 and $250 work fine.” What is wrong with this plan and what BVA test values would you add?

A: Testing $0 and $250 only covers the middle of the valid partition — it cannot catch whether the $500 threshold is coded as < or ≤. An off-by-one error at exactly $500 would silently deny or accept the wrong applicants, with real financial consequences for vulnerable people. Using 2-value BVA, add $500 (boundary — check whether it accepts or rejects per the spec, and confirm inclusive vs exclusive with the business analyst) and $501 (just above — must reject). If the spec says “exceeds $500”, then $500 should accept and $501 should reject; if it says “$500 or more”, then $500 should reject. That distinction is exactly where the bug lives.

Q7: When should you choose 3-value BVA over 2-value BVA for an Revenue NZ or CoverNZ system boundary, and when is the extra test case not worth the effort?

A: Choose 3-value BVA when the boundary carries financial, legal, or compliance consequences — for example, the threshold above which Revenue NZ applies a late-filing penalty, or the CoverNZ weekly compensation cap where a one-unit error directly affects a claimant’s payout. The extra “just inside” value catches cases where the correct boundary value passes but the immediately adjacent valid value fails due to a logic error in a compound condition. Skip it when the boundary is low-risk (a search-results page limit, a UI character count), when test execution time is tightly constrained, or when a well-reviewed unit test already covers the inside edge — use the time saved for exploratory testing of higher-risk areas instead.

Q8: What is the key difference between Boundary Value Analysis and Equivalence Partitioning, and why does applying EP alone miss the most common type of coding defect?

A: Equivalence Partitioning divides inputs into groups (partitions) where all values in a group are expected to behave the same, then tests one representative value from the middle of each group. BVA tests the values at and just outside the edges where two partitions meet. The most common coding defect — an off-by-one error such as < instead of ≤ — produces identical behaviour for any mid-partition value because the logic is only wrong at the exact limit. EP confirms that the partitions exist; BVA confirms that the fence between them is in the right place. You need both: EP for coverage breadth, BVA for boundary precision.

Q9: A developer tells you, “I already tested the TransitNZ vehicle weight limit at 44,000 kg and it accepted — you don’t need to test 44,001 kg because the UI blocks you entering more than five digits.” What is wrong with this reasoning and how do you respond?

A: Front-end validation and the underlying business rule are two separate things. Blocking input in the UI does not mean the back-end correctly enforces the boundary — API calls, data imports, integrations with TransitNZ’s fleet management systems, and bulk migrations can all bypass the UI entirely and submit values of any size. The just-outside value (44,001 kg) is specifically designed to verify that the system correctly rejects out-of-range data regardless of how it arrives. A system that silently accepts 44,001 kg from an API while the UI blocks it has a hidden defect waiting for the first non-UI data path. Testing only through the UI is a coverage gap, not a test of the boundary rule itself.

★ Interview Questions

What NZ hiring managers ask about Boundary Value Analysis — and what strong answers look like at each level.

Q: What is Boundary Value Analysis and why do testers bother with it when Equivalence Partitioning already covers the same input ranges?

Strong answer: BVA focuses on the values at and just outside the edges of a valid range, because off-by-one coding errors — writing < instead of ≤ — only produce wrong behaviour at the exact limit. EP picks a comfortable mid-range value that behaves identically whether the code is right or wrong; BVA picks the one value that can tell them apart. The two techniques complement each other: EP confirms the partitions exist, BVA confirms the fence between them is in the right place.

Grad / Junior

Q: A KiwiSaver contribution-rate field accepts whole percentages from 3 to 10 inclusive. Walk me through your 2-value BVA test cases and explain what bug each boundary pair is designed to catch.

Strong answer: The four test cases are: 2 (reject — just below the lower boundary, catches a >3 instead of ≥3 error that would wrongly exclude the minimum valid rate), 3 (accept — the lower boundary itself, confirms it is inclusive), 10 (accept — the upper boundary, confirms it is inclusive), and 11 (reject — just above the upper boundary, catches a ≤10 failing silently when an out-of-range value slips in via API or data migration). I would also confirm with the BA whether the spec says “3 to 10” or “3 or more up to 10” — the wording nails the inclusive vs exclusive question before I write a single expected result.

Junior

Q: You are testing an Revenue NZ income-threshold field where a penalty applies above $48,000. The developer says the UI already blocks anything over five digits, so the just-above boundary value is impossible to enter. How do you respond?

Strong answer: I would still test 48,001 — through the API, not the UI. Front-end validation and back-end business rules are separate layers; data imports, automated payroll integrations, and bulk migrations all bypass the UI entirely. If the back end silently accepts $48,001 without applying the penalty, Revenue NZ has a compliance defect that will never surface in browser testing. I would log a test case explicitly targeting the API endpoint, document the UI-vs-API gap in the test plan, and flag it as a risk so the product owner understands the coverage boundary.

Senior

Q: When would you recommend 3-value BVA over 2-value BVA for an CoverNZ or Benefits NZ system, and are there situations where you would skip BVA entirely even though a numeric boundary exists?

Strong answer: I escalate to 3-value BVA when the boundary carries financial or legal consequences — CoverNZ weekly compensation thresholds, Benefits NZ Jobseeker income limits, or RBNZ capital ratio cutoffs — because a compound condition can pass at the boundary itself but fail one unit inside, and the extra “just inside” value is the only test that finds it. I would skip BVA or deprioritise it when: the UI control physically prevents out-of-range input and there is no API or import path; the range has hundreds of valid discrete values with low business risk; or a well-reviewed unit test already covers the boundary with 100% confidence and my regression time is better spent on exploratory testing of higher-risk flows.

Senior

Q: A developer on your squad pushes back every sprint, saying boundary tests are redundant because “no real user enters $10,001.” How do you build team-wide adoption of BVA without it feeling like a bureaucratic checkbox?

Strong answer: I bring a real example from our own codebase or NZ context — the Harbour Bank savings-bonus off-by-one, or a TransitNZ permit weight that silently accepted 44,001 kg via a batch import — and frame it as “real users don’t, but integrations do.” I then work with the team to embed the two just-outside values into the Definition of Done for any story with a numeric or date boundary, so it is a quality gate rather than an optional extra. Over time I track boundary bugs found in production vs caught in BVA, share that data in retros, and let the metrics make the case. The goal is a habit, not a rule: testers who understand why boundaries matter stop needing to be reminded.

Lead / Principal

Enterprise reality

200+ test cases, regulated systems, automated BVA at CI scale

  • Boundary tables are generated from spec, not hand-crafted — engineers write generators that read the acceptance criteria and emit the four or six BVA values automatically. A team with 200+ boundary fields cannot afford to derive values by hand every sprint.
  • Automated BVA suites become regression assets maintained across releases. Once a boundary test is parameterised (input: value, threshold, inclusive/exclusive; expected: accept/reject), it runs in CI on every merge and flags any regression the moment a developer accidentally changes a comparison operator.
  • Regulated environments require traceability: each boundary maps to a named requirement, a risk level, and an audit trail. For Revenue NZ, CoverNZ, or RBNZ systems, the test case is not just a pass/fail row — it is evidence in a compliance report that the threshold was deliberately verified at the correct value on a specific build.
  • Coverage reporting shows boundary hit rates across the test run, not just pass/fail counts. At scale, a dashboard that shows "94% of defined boundary values executed" gives architects and QA leads the signal they need to prioritise the remaining gaps before a release sign-off — a level of visibility that manual tracking cannot provide.

◆ What I would do

Professional judgment — when to reach for Boundary Value Analysis, when to skip it, and what to watch for.

If…
I am testing an CoverNZ weekly compensation threshold, an Revenue NZ late-filing penalty cutoff, or any TransitNZ vehicle classification boundary where a one-unit error has a financial or legal consequence
I would…
Apply 3-value BVA, run tests at the API layer (not just the UI), confirm inclusive vs exclusive directly with the BA in writing, and document the data type of the underlying column. The cost of a missed off-by-one at these boundaries is a compliance breach, not just a UI glitch.
If…
The sprint is tight and I have a low-risk UI field with a numeric range — say, a search-results page size selector that accepts 10–100 — and there is no API exposure
I would…
Apply 2-value BVA for the two just-outside values only (9 and 101), skip 3-value, and use the time I save for exploratory testing on the riskier flows. Boundary testing on low-stakes UI fields is about coverage hygiene, not defect prevention.
If…
A developer pushes back on boundary testing by saying the field is protected by a well-reviewed unit test that already covers the edge cases
I would…
Ask to see the unit test and check three things: it tests the boundary at the same layer as the defect risk (e.g. service layer, not just the model), it uses the same data type as production (integer, not float), and it covers a just-outside invalid value that would be rejected. If all three are true, I skip the duplicate system test and log the unit test reference in my test plan. If any are missing, I test at the system level anyway.

The bottom line: BVA is not about being thorough for its own sake — it is about going to the exact place where the most common category of coding defect lives and putting a test there before the code ships, because no amount of happy-path testing will ever find it.

Key takeaway

The boundary is not where the spec says the rule lives — it is where the developer's < versus <= decision lives, and those two things are rarely in the same sentence; your job is to put a test at the exact value that can tell them apart.

Always pair with Equivalence Partitioning — EP defines the partitions, BVA tests their edges.

When multiple input boundaries interact, consider Decision Table Testing or pairwise combinatorial testing.

Practice this technique: Try Junior Practice 09 — Checkbox & radio logic, Junior Practice 07 — Date picker issues, Junior Practice 05 — Payment form validation.

NZ example — KiwiSaver contribution rates

KiwiSaver employee contribution rates have defined thresholds: 3%, 4%, 6%, 8%, 10%. A contribution rate field that accepts values from 3 to 10 (as a percentage, integers only) has boundaries at 3 (minimum) and 10 (maximum).

KiwiSaver contribution rate — BVA test cases

  • 2-value BVA: test 2 (just below minimum — should reject), 3 (minimum — should accept), 10 (maximum — should accept), 11 (just above maximum — should reject).
  • 3-value BVA adds: 4 (just above minimum — accept) and 9 (just below maximum — accept).

The off-by-one error risk is real here: a developer coding > 3 instead of >= 3 would reject the minimum valid contribution rate, leaving employees unable to set 3%.

Try it yourself

KiwiSaver contribution rate — 2-value BVA

A KiwiSaver contribution rate field accepts whole numbers from 3 to 10 (inclusive). Using 2-value BVA, fill in all 4 boundary test values and select the expected result for each.

# Test value Expected result
1
2
3
4

Full answer — 2-value BVA for contribution rates 3–10:
#Test valueBoundary typeExpected result
12Just below lower boundaryReject
23Lower boundary (minimum)Accept
310Upper boundary (maximum)Accept
411Just above upper boundaryReject

Bonus (3-value BVA): Add 4 (just above lower boundary — Accept) and 9 (just below upper boundary — Accept).

← Equivalence Partitioning Next: Decision Table Testing →
Continue Learning

Prerequisites

Related Techniques

What to Learn Next

Also in Bootcamp