Boundary Value Analysis
A testing technique that focuses on testing values at the edges of input ranges.
Full Definition
Boundary Value Analysis (BVA) is a black-box test design technique that focuses on testing at the boundaries — or edges — of input ranges. The underlying principle is that defects are disproportionately likely to occur at the boundaries of valid input ranges rather than in the middle. When a developer writes code to handle values between 1 and 100, the logic at exactly 1, exactly 100, just below 1 (0), and just above 100 (101) is where errors most commonly hide — off-by-one errors, incorrect comparison operators (< vs. <=), and boundary-handling omissions.
Why boundaries matter:
- •Off-by-one errors are among the most common programming mistakes —
if (age > 18)vs.if (age >= 18)behaves differently only at the boundary value of 18 - •Developers often handle the "middle" of a range correctly but make errors at transitions between valid and invalid inputs
- •Boundary testing provides maximum defect detection with minimum test cases — testing 4-6 boundary values is more effective than testing dozens of random values
BVA values to test for a range [min, max]:
- •min - 1: Just below the minimum (invalid) — should be rejected
- •min: The minimum valid value — should be accepted
- •min + 1: Just above the minimum (valid) — should be accepted
- •max - 1: Just below the maximum (valid) — should be accepted
- •max: The maximum valid value — should be accepted
- •max + 1: Just above the maximum (invalid) — should be rejected
Applying BVA to different data types:
- •Numeric ranges: Test the exact boundary numbers (e.g., for age 18-65: test 17, 18, 19, 64, 65, 66)
- •String lengths: Test at minimum and maximum length limits (e.g., password 8-20 chars: test 7, 8, 9, 19, 20, 21 characters)
- •Date ranges: Test the first and last valid dates, and dates just outside the range
- •Collection sizes: Test with empty collections, single elements, and maximum allowed elements
- •File sizes: Test at upload limits (e.g., 10MB limit: test 9.9MB, 10MB, 10.1MB)
BVA combined with Equivalence Partitioning:
BVA is most effective when used alongside Equivalence Partitioning (EP) — a technique that divides inputs into groups (partitions) where all values in a partition are expected to behave the same way. EP identifies the partitions (valid range, below range, above range); BVA identifies the specific values to test at the boundaries between partitions. Together, they provide efficient yet thorough input coverage.
Two-value vs. three-value BVA:
- •Two-value BVA: Tests only the boundary values (min, max) and just outside (min-1, max+1). Produces 4 test values. More efficient.
- •Three-value BVA: Also tests just inside the boundary (min+1, max-1). Produces 6 test values. More thorough.
- •The choice depends on risk tolerance and the complexity of the boundary handling logic.
Common mistakes in boundary value analysis:
The most common error is applying BVA only to obvious numeric inputs and forgetting about other types of boundaries: string lengths, array sizes, date ranges, file sizes, and even business rule thresholds (e.g., free shipping over $50 — test $49.99, $50.00, $50.01). Another mistake is testing boundaries in isolation without considering interactions between multiple bounded inputs. A form with three bounded fields has boundary combinations that single-field BVA won't cover. Teams also sometimes confuse BVA with random testing of extreme values — BVA is systematic and targeted at the specific transition points between valid and invalid ranges.
Best practices:
- •Identify all input boundaries during test design, including those not explicitly stated in requirements (implicit boundaries like maximum database field lengths)
- •Apply BVA to output boundaries too — verify that outputs at range limits are correct (e.g., a discount that caps at 50%)
- •Combine BVA with equivalence partitioning for a comprehensive test design strategy
- •Document the boundary conditions being tested in the test case — make the rationale explicit
- •Consider multi-variable boundary testing for features with interacting bounded inputs
Examples
- 1.Testing a quantity field that accepts values 1-99: testing with 0 (reject), 1 (accept), 2 (accept), 98 (accept), 99 (accept), and 100 (reject) — catching an off-by-one error where the developer used < 99 instead of <= 99
- 2.Password length validation (8-20 characters): testing with 7-character password (should fail), 8-character password (should pass), 9-character password (should pass), 19-character password (should pass), 20-character password (should pass), and 21-character password (should fail)
- 3.Age eligibility for a service (18-65 years): testing with ages 17 (ineligible), 18 (eligible), 19 (eligible), 64 (eligible), 65 (eligible), and 66 (ineligible) — verifying the system correctly handles the boundary transitions
- 4.File upload with a 10MB limit: testing with a 9.9MB file (accepted), a 10.0MB file (accepted), and a 10.1MB file (rejected with a clear error message indicating the maximum allowed size)
- 5.Date range filter for a report (Jan 1 to Dec 31, 2025): testing with Dec 31, 2024 (excluded), Jan 1, 2025 (included), Jan 2, 2025 (included), Dec 30, 2025 (included), Dec 31, 2025 (included), and Jan 1, 2026 (excluded)
- 6.Free shipping threshold at $50: testing cart totals of $49.99 (shipping charged), $50.00 (free shipping applied), and $50.01 (free shipping applied) — verifying the business rule boundary is implemented correctly
In BesTest
BesTest supports creating systematic boundary value test cases where each step documents the specific boundary condition being tested and the expected behavior at that threshold. The structured preconditions and expected results fields are ideal for BVA, where precision about input values and expected outcomes is critical. The review workflow validates that boundary conditions are documented clearly.
Related Terms
Test Case
A documented set of conditions and steps used to verify that a software feature works as expected.
Test Data
The input values, datasets, and environmental data used during test execution.
Test Coverage
A measure of how much of the software or requirements are tested by test cases.
Expected Result
The anticipated outcome of a test case step or the test case as a whole.
Test Execution
The process of running test cases and recording the actual results.
See Boundary Value Analysis in Action
Experience professional test management with BesTest. Free for up to 10 users.
Try BesTest Free