Boundary Value Analysis With Examples (2026)

TL;DR

Boundary value analysis tests the points where expected behavior changes. For an inclusive integer range from 18 to 60, the core robust set is 17, 18, 19, a nominal value, 59, 60, and 61, with each expected result derived from the requirement rather than guessed.

Key Takeaways

• Boundary value analysis targets values at and immediately around a rule transition because defects cluster where behavior changes.
• Write the valid and invalid partitions first, then identify every inclusive, exclusive, discrete, or continuous boundary.
• For an inclusive range, test just below minimum, minimum, just above minimum, just below maximum, maximum, and just above maximum.
• Use robust BVA for one invalid boundary at a time and worst-case BVA only when interactions justify the larger combination set.
• Translate vague words such as between, up to, and less than into mathematical rules before designing cases.
• Automate deterministic boundary sets while preserving expected outcomes, units, and traceable requirement IDs.

Boundary value analysis with examples is easiest to understand as testing the seams in a rule. If a system accepts ages from 18 through 60, behavior changes at 18 and again after 60. Values at, immediately below, and immediately above those transitions are more revealing than several arbitrary values from the middle.

BVA is a black-box test design technique, but effective use requires more than copying min - 1, min, max, max + 1. You must identify partitions, units, inclusivity, data type, dependent fields, and business transitions. This guide shows how to derive, document, automate, and review boundary tests for realistic software.

TL;DR

For an inclusive integer input 18 <= age <= 60:

This seven-value robust set tests both valid and invalid neighbors. Add empty, null, wrong type, and formatting tests through other techniques because they are not numeric boundary neighbors.

1. What Boundary Value Analysis With Examples Reveals

Boundary value analysis, or BVA, selects test inputs near limits where the system changes classification or behavior. The limit might be numeric, but boundaries also occur in string length, dates, file size, list count, pagination, rate limits, state transitions, and timing windows.

The defect hypothesis is practical: implementation logic often fails at comparison operators, indexing, rounding, unit conversion, and range endpoints. A developer may implement age > 18 when the requirement says 18 is allowed, use pageSize < 100 instead of <= 100, or allocate an array with one fewer slot. A middle value such as 35 cannot distinguish those implementations. The boundary value can.

Consider a password length rule of 8 through 64 characters. The important length transitions are 7 to 8 and 64 to 65. The actual character content belongs to other rules such as allowed characters and complexity. Good BVA isolates the length variable first, then combines it with other factors only where interaction risk warrants it.

BVA does not prove the entire feature. It provides efficient coverage of transitions. Pair it with equivalence partitioning, decision tables, state-transition testing, pairwise testing, exploratory testing, and risk analysis. The black-box test design techniques guide shows how these methods complement one another.

2. Start With Equivalence Partitions

Equivalence partitioning divides the input domain into classes expected to behave the same. Boundary analysis then samples the edges between those classes. Deriving partitions first prevents a mechanical boundary list from overlooking a whole business category.

For 18 <= age <= 60, the primary partitions are:

• Invalid low: age less than 18.
• Valid: age from 18 through 60.
• Invalid high: age greater than 60.

BVA selects representatives around the two transitions. It does not automatically cover missing input, decimal input, text input, or values outside the storage type. Those may form additional partitions based on the interface contract.

Suppose a shipping rule says orders below $50 pay $6, orders from $50 through $99.99 pay $3, and orders of $100 or more ship free. There are three valid behavior partitions and two price boundaries. Testing only minimum and maximum would miss the shipping transition at $50 and $100. Every change in expected outcome is a boundary, even when the total domain has no stated maximum.

Write partitions in a table with condition, expected behavior, and source requirement. Then mark adjacent classes. Each adjacency creates a candidate boundary. This requirement-first process makes test cases traceable and exposes ambiguity before automation begins.

3. Translate Requirements Into Precise Rules

Natural language often hides whether an endpoint is included. Words such as 'between,' 'up to,' 'over,' and 'within' are not precise enough for test design. Convert each rule into mathematical or logical notation.

Record the data type and smallest meaningful increment. For integers, the neighbor of 18 is 17 or 19. For currency with two decimal places, the neighbor of $50.00 may be $49.99 and $50.01. For timestamps, it may be one millisecond, one second, or one business day depending on stored precision and requirement semantics.

Also identify normalization. Does the API round 49.999, reject it, or store three decimals? Does a text field count Unicode code points, UTF-16 units, bytes, or user-perceived characters? The expected boundary cannot be correct until the measurement rule is explicit.

4. Traditional, Robust, and Worst-Case BVA

Several BVA variants differ in how many values they select and whether invalid neighbors or combinations are included.

For n independent variables, classic normal BVA often produces 4n + 1 cases: four near-boundary values for one variable while others remain nominal, plus the all-nominal case. Robust BVA often produces 6n + 1 by adding invalid values just outside each range. These counts are modeling conventions, not mandatory targets.

Worst-case BVA combines boundary values across variables. With five selected values for each of three inputs, that creates 5^3 = 125 cases. Use it when failures may emerge from boundary interactions and the cost is justified. Do not generate a Cartesian product merely because a tool can. Pairwise coverage, decision tables, or risk-selected combinations often provide better economics.

State which variant you use in the test plan. 'BVA complete' is ambiguous unless reviewers know whether invalid neighbors and interactions were included.

5. Step-by-Step Boundary Value Analysis Process

Use this repeatable workflow:

1. Identify the unit under test. Choose the API field, UI control, calculation, collection, or state rule.
2. Extract constraints. Record minimums, maximums, transitions, data type, precision, inclusivity, and dependencies.
3. Define partitions. List each valid and invalid class with its expected outcome.
4. Mark every transition. Include internal business thresholds, not only domain endpoints.
5. Choose neighbor distance. Use the smallest meaningful increment for the contract.
6. Select a BVA variant. Normal, robust, or interaction-focused worst-case.
7. Hold unrelated variables nominal. Isolate one boundary unless testing an intentional interaction.
8. Write expected results first. Include response code, validation message, stored value, and downstream effect where relevant.
9. Review ambiguity. Resolve unclear terms with product and engineering before marking tests final.
10. Automate stable cases. Keep the data table readable and map failures back to boundary labels.

A boundary table should include more than input and pass/fail. Add a boundary label, requirement ID, expected classification, and notes about units. For an API, specify whether invalid input produces 400 or 422, the error field, and whether anything was persisted. For a UI, check both inline feedback and prevention of submission.

This process also supports reviews. A product owner can confirm the rule, a developer can inspect comparison logic, and an automation engineer can build data-driven cases from the same artifact.

6. Boundary Value Analysis With Examples for Age and Quantity

Consider a membership form that accepts integer age from 18 through 60 and ticket quantity from 1 through 6. Start by varying one field while the other stays nominal.

Age boundary cases

Quantity boundary cases

Use quantity values 0, 1, 2, 3, 5, 6, and 7 while age remains 39. These cases isolate the quantity comparison. Then add selected interactions such as minimum age with maximum quantity if discounts, inventory, or authorization logic links the fields.

Do not assume robust worst-case combinations are needed. If age only controls eligibility and quantity only controls capacity, one-at-a-time BVA may be sufficient. If minors can buy zero tickets, or age controls the quantity limit, the variables are dependent and require a decision table.

Add type partitions separately: empty, whitespace, 18.5, 018, 1e2, negative sign formatting, and numeric values beyond storage range. They are valuable tests, but calling all of them BVA obscures which defect hypothesis each case addresses.

7. Test String Length and Unicode Boundaries

A username rule might allow 3 through 20 characters. The robust length values are 2, 3, 4, a nominal length, 19, 20, and 21. Use simple characters first to isolate length, for example repeated a characters.

Then ask what 'character' means. In Java, String.length() counts UTF-16 code units, not necessarily user-perceived characters. Some emoji use surrogate pairs, and combined accents may contain multiple code points while appearing as one glyph. A database column or downstream service may measure encoded bytes instead.

Create separate cases for:

• ASCII strings at each length boundary.
• A supplementary Unicode character near the limit.
• A combining sequence near the limit.
• Leading or trailing whitespace if trimming occurs.
• Normalized and non-normalized forms if identity comparisons matter.
• Maximum encoded byte length when the storage contract is byte-based.

The expected result must state when normalization and counting occur. If the client counts before trimming but the server counts after trimming, a 21-character input containing spaces may produce inconsistent behavior. That is a contract defect, not merely a test failure.

For passwords, do not log actual values or include real credentials in boundary reports. Generate synthetic strings by length and report the boundary label. The form validation test cases guide covers required, format, and security partitions that complement length BVA.

8. Test Dates, Durations, and Time Zones

Date boundaries are deceptively complex because the neighbor distance and time zone affect classification. Suppose cancellation is allowed until 24 hours before an event at 2026-08-20T10:00:00Z. The transition instant is 2026-08-19T10:00:00Z.

If the rule is inclusive, test:

• One supported tick before the cutoff.
• Exactly at the cutoff.
• One supported tick after the cutoff.

Also test the business representation. A rule stated as 'the day before' may mean a calendar boundary in the venue's time zone, not 24 elapsed hours. Daylight-saving transitions can make a local day shorter or longer than 24 hours. Store instants and named zones deliberately, and avoid deriving expectations from the same production helper being tested.

For age calculations, the boundaries are birthdays, not an approximate number of milliseconds. Test one day before the qualifying birthday, on the birthday, and one day after. Include a leap-day birth when policy must decide how eligibility works in non-leap years.

For session expiration, distinguish inactivity duration from absolute lifetime. Exercise just before expiry, exactly at expiry, and just after, then verify both user-facing behavior and token rejection at the service. Keep test clocks controllable where possible. Sleeping until a real timeout makes suites slow and unreliable.

9. Test Money, Rounding, and Tiered Pricing

Money rules often have internal boundaries and precision behavior. Assume shipping costs $6 below $50.00, $3 from $50.00 through $99.99, and $0 at $100.00 or more. With cents as the smallest supported unit, high-value cases include:

Then separate raw-input precision from business subtotal precision. If an API accepts three decimal places, test 49.994, 49.995, and 49.996 only after the rounding mode is specified. Binary floating-point can represent decimal values unexpectedly, so financial code should usually use decimal types and an explicit rounding policy.

Discounts and taxes introduce order-of-operation boundaries. Does free shipping use the subtotal before or after discount? Is tax applied before comparing a credit limit? Create a decision table for those rules and apply BVA to each calculated threshold. Never compute the expected total by calling the same production method as the system under test. Use an independent oracle with visible examples.

10. Test API Pagination, Limits, and Collections

APIs expose boundaries in page size, item count, offsets, payload size, and rate limits. Suppose pageSize accepts integers 1 through 100. Robust values are 0, 1, 2, a nominal value, 99, 100, and 101. Expected results should include HTTP status, error schema, defaulting behavior, and returned item count.

Collection boundaries require data setup. For a page size of 100, test datasets containing 0, 1, 99, 100, and 101 total records. These inputs answer different questions from the parameter boundary:

• Empty dataset returns a valid empty collection.
• One record does not create a phantom next page.
• Exactly 100 records fills one page.
• 101 records exposes the second-page transition.
• Sorting remains stable across the page boundary.

For upload limits, clarify units and enforcement layer. A 10 MB limit may mean 10,000,000 bytes or 10,485,760 bytes. Test one byte below, exactly at, and one byte above the specified number. Check reverse proxies, application servers, and storage services because each can enforce a different limit and produce a different error.

Rate-limit tests need controlled clocks and isolated credentials. Verify the request immediately before the threshold, the threshold request, and the first rejected request according to the exact counting rule. Also validate reset behavior at, before, and after the window boundary without overloading a shared environment.

11. Automate Boundary Cases Without Hiding Intent

A data-driven test should preserve the label and expected behavior for every case. This runnable Playwright example uses a self-contained HTML form, so it does not depend on an external site:

import { test, expect } from '@playwright/test';

const cases = [
  { age: 17, accepted: false, label: 'just below minimum' },
  { age: 18, accepted: true, label: 'minimum' },
  { age: 19, accepted: true, label: 'just above minimum' },
  { age: 59, accepted: true, label: 'just below maximum' },
  { age: 60, accepted: true, label: 'maximum' },
  { age: 61, accepted: false, label: 'just above maximum' },
];

for (const boundary of cases) {
  test('age ' + boundary.label + ': ' + boundary.age, async ({ page }) => {
    await page.setContent(`
      <label>Age <input aria-label="Age" type="number"></label>
      <button>Check</button><p role="status"></p>
      <script>
        document.querySelector('button').onclick = () => {
          const age = Number(document.querySelector('input').value);
          document.querySelector('[role=status]').textContent =
            Number.isInteger(age) && age >= 18 && age <= 60 ? 'Accepted' : 'Rejected';
        };
      </script>
    `);

    await page.getByLabel('Age').fill(String(boundary.age));
    await page.getByRole('button', { name: 'Check' }).click();
    await expect(page.getByRole('status')).toHaveText(
      boundary.accepted ? 'Accepted' : 'Rejected'
    );
  });
}

Keep curated boundary cases in source control. A generator can produce neighbors, but reviewers should see the rule, increment, and expected classification. For compound inputs, generate candidates and then select risk-based combinations rather than publishing an unreadable matrix. See data-driven testing in Playwright for fixture and reporting patterns.

12. Measure Coverage and Maintain Boundary Tests

Boundary coverage should map to rules, not merely lines of code. Maintain an inventory of constraints and record which tests cover the value at each boundary, valid neighbor, and invalid neighbor. For multi-variable rules, record the interaction strategy separately.

A useful review checklist asks:

• Did we identify every behavior transition, including internal pricing and permission thresholds?
• Are inclusivity and units explicit?
• Is the neighbor distance correct for the data type and stored precision?
• Are valid and invalid outcomes checked beyond a generic error message?
• Are server-side rules tested independently from client-side validation?
• Do localization, time zone, rounding, or normalization alter the boundary?
• Are selected interactions justified by risk?
• Can a reviewer trace each case to a requirement or resolved product decision?

When requirements change, update the boundary table before the automation data. If the maximum attachment count changes from 5 to 10, old cases around 5 may still matter if another tier or warning remains there. Do not mechanically replace numbers without reviewing behavior transitions.

Production defects can reveal missed boundaries. Add the failure as a regression case, then improve the model so similar transitions are found elsewhere. The test case review checklist helps teams evaluate completeness without rewarding raw case count.

Interview Questions and Answers

Q: What is boundary value analysis?

It is a black-box technique that selects test values at and immediately around points where expected behavior changes. It is based on the risk that defects cluster around comparisons, endpoints, indexing, precision, and transitions.

Q: How is BVA related to equivalence partitioning?

Equivalence partitioning defines classes expected to behave alike. BVA targets the edges between those classes, so partitions should normally be identified before boundary values are selected.

Q: What values would you test for an inclusive range 1 through 100?

A robust set is 0, 1, 2, a nominal value, 99, 100, and 101. The exact nominal value is less important than correct coverage of both transitions.

Q: What is robust boundary value analysis?

Robust BVA adds values just outside the valid minimum and maximum. It verifies how the system rejects invalid neighbors while normal BVA focuses on values within the valid range.

Q: When would you use worst-case BVA?

Use it when several input boundaries may interact and the risk justifies combination coverage. Because the Cartesian product grows quickly, apply it selectively or use another combinatorial technique.

Q: Can BVA be applied to nonnumeric inputs?

Yes. Length, dates, collection size, file bytes, page counts, timing windows, and state limits all have boundaries when a meaningful order and neighbor relationship exist.

Common Mistakes

• Applying min - 1 and max + 1 without defining the data type or smallest meaningful increment.
• Treating only the overall minimum and maximum as boundaries while missing internal tiers.
• Assuming 'between' or 'up to' communicates inclusivity.
• Mixing empty, null, format, and security tests into BVA without identifying their separate partitions.
• Using the same production calculation to generate expected results.
• Combining every boundary across every field and creating an unmaintainable suite.
• Testing client-side validation but not the server rule.
• Ignoring Unicode measurement, time zones, decimal rounding, and byte units.
• Leaving unrelated fields at invalid or unstable values while trying to isolate one boundary.
• Recording only pass or fail instead of the expected message, status, persistence, and downstream behavior.

Conclusion

Boundary value analysis with examples turns vague test intuition into a reviewable method. Define partitions, translate requirements into precise rules, identify every behavior transition, and test at and on both sides using the correct unit of change.

Start with robust one-variable boundary sets, then add interactions where business risk supports them. Preserve boundary labels and expected outcomes in automation, and revisit the model whenever the requirement, precision, or implementation layer changes.

Interview Questions and Answers

Frequently Asked Questions

Related Guides

• Equivalence partitioning with examples (2026)
• Severity vs priority with examples (2026)
• Accessibility testing with Cypress (2026)
• Accessibility testing with Playwright (2026)
• Agentic testing with tool calling (2026)
• AI for flaky test root cause analysis (2026)