Boundary Value Analysis: The Functional Testing Technique That Catches Off-By-One Bugs

A team deploys a nightly export that runs clean on 999 users in staging and times out at exactly 1,000 in production. Nobody typed “1,000” in the spec. There’s no form to validate, no age range to check. The boundary is real, and the test suite never touched it.

That’s the gap most testing writing leaves open. Boundary value analysis (BVA) gets described as a technique for testing form inputs at the edges: age 17, 18, 19 and 64, 65, 66. That works for the form and misses everything else. In practice, boundaries live in cookie sizes, cron schedules, connection pools, and batch runtimes, and none of them are written down anywhere a tester would think to look. For founders and product leads, the business cost of missing them is straightforward: a boundary that trips in production is a support fire, a churned customer, and a delayed roadmap. This is precisely where a systematic functional testing sweep earns its budget back.

This piece maps the five places boundaries actually hide in a shipped product, and what to test at each one.

The Boundary Nobody Wrote Down

Boundary value analysis in software testing is a test design technique that targets the values sitting on the edges of a system’s behavior, the point where one rule ends and another begins. The textbook version handles input ranges. The useful version handles everything else.

Most competitors stop at the input form because that’s where the boundary is easy to see. A field says “18 to 65.” Test 17, 18, 65, 66. Done. Real products have hundreds of boundaries the spec never mentions: the size a session cookie can grow before the browser drops it, the row count a Lambda can process before the runtime kills it, the exact millisecond a rate-limit window resets. Every one of them is a boundary. None of them look like one until they break.

The reframe worth carrying through the rest of this piece: boundary value analysis is a boundary-discovery discipline, not a value-substitution exercise. The tester’s job is to find where the system changes behavior, then probe each spot.

Why Off-By-One Bugs Still Ship

Off-by-one bugs still ship because requirements docs describe the happy input, testers test what’s written, and implicit boundaries only show up under load. The Consortium for Information & Software Quality reported the cost of poor software quality in the United States at $2.41 trillion in its most recent analysis, and a meaningful slice of that number is the boundaries nobody bothered to document.

Three patterns drive it:

• The 1,000-row batch cap lives in the job runner’s timeout config, not the PRD
• If nobody writes “cookie size must stay under 4 KB,” nobody adds a test for it
• Explicit boundaries get automated in unit tests during development; implicit ones get discovered by users at 2 a.m.

The Uptime Institute’s 2025 Annual Outage Analysis reports that 85% of human-error outages trace back to staff failing to follow procedures or to flaws in the procedures themselves. Missing tests for undocumented boundaries fall squarely into the second bucket. Stop asking “what’s the range in the spec.” Start asking “where does this system change behavior.”

Boundary Value Analysis vs Edge Case Testing

The two terms get used interchangeably, which hides a useful distinction. BVA is numeric and precise: it lives at a measurable threshold like row 999 vs. 1,000 or byte 4,095 vs. 4,096. Edge case testing is broader, covering weird states and unusual combinations that may not have a clean numeric edge, such as an offline device, a user with zero permissions, or a corrupted upload.

Every boundary is an edge case. Not every edge case is a boundary. If you can put a number on where the behavior changes, BVA is the right tool. If the change is qualitative rather than quantitative, edge case testing is the better fit, and it covers a wider slice of “where requirements end and reality starts”.

Five Places Boundaries Hide

Below are the five categories where boundaries live that the requirements doc doesn’t list. Each opens with a bug pattern, names the boundary nobody documented, and gives the test cases that surface it. A concrete boundary value analysis example lives in each category rather than in a single toy field.

Infrastructure Limits Nobody Documented

A user’s session cookie grows past 4 KB after adding a fifth OAuth provider, and every subsequent request drops the session silently. A URL with 50 filter parameters exceeds the 8 KB header limit of a downstream proxy, and the API returns 400 with no logged reason. Neither limit sits in the product spec. Both sit in a config file.

The hidden boundaries at this layer include:

• Cookie size, capped around 4 KB per cookie in most browsers
• HTTP header size, typically 8 to 16 KB depending on the server
• URL length, with practical CDN and browser caps around 2 KB
• Request body size, defaulting to 1 MB in nginx
• Packet MTU at 1,500 bytes on standard Ethernet

Test cases worth adding: payload just under and just over each cap, a session cookie approaching 4 KB, a URL with enough query parameters to cross 2 KB, an upload sized to straddle the proxy’s body limit. Check the config, not the spec. When these show up at the API layer, API testing is where they get caught.

Time And Calendar Traps

Time is the category that punishes assumptions hardest. A subscription billed on the 31st charges twice in March and skips April. A cron job scheduled for 2:30 a.m. runs twice on the fall daylight saving switch and not at all in the spring. A timestamp field written as int32 will overflow on January 19, 2038, at 03:14:07 UTC, and the Year 2038 problem is a boundary with a date on it.

The temporal boundaries to test include month-end transitions across 28, 29, 30, and 31-day months, leap day, DST transitions in both directions, ISO week 53 rollovers, and billing anniversaries that shift when a month has fewer days than the anniversary date. Set up a subscription on January 31, advance the clock through February 28, and watch what the billing engine does. Run a scheduled job across a DST boundary in a DST-observing timezone. Book a hotel with check-in on February 28, 2028 and check-out on March 1.

Data Type Ceilings

A view counter stored as INT hits 2,147,483,647, and the next increment either wraps to a negative number or throws. A currency field stored as float accumulates rounding errors and a $100.00 invoice reconciles as $99.9999998. A username column widened from VARCHAR(50) to VARCHAR(100) between releases silently truncates rows migrated from the old schema.

The boundaries hiding in the schema:

Read the schema before writing the test plan. These boundaries are invisible in the UI and obvious in the database.

Pagination and Batch Cliffs

Pagination boundaries live at the first page, the last page, and the transition between pages when the total is an exact multiple of page size. Batch boundaries live at whatever runtime cap the executor enforces, whether it’s Lambda’s 15 minutes, Cloud Run’s 60 minutes, or the 5-minute cron the SRE team set two years ago.

The classic pattern: an export processes 999 rows in staging and times out at 1,000 in production because the real boundary is the runtime limit, not the row count. Another one: a list view shows 10 items per page and page 10 renders empty because the cursor logic is offset = page × limit, with page indexing starting at 1 in the URL and 0 in the query.

Cases to add: load exactly page_size × N records and request page N and N+1. Request page 0 and page −1. Run the batch job on a dataset one row above the observed timeout threshold. Export a table with exactly the tool’s row limit; Google Sheets caps at 10 million cells, Excel at 1,048,576 rows.

Concurrency Thresholds

The 5th concurrent user on a session-limited account triggers an eviction of session 1, but the eviction lock deadlocks with the login flow. The database connection pool is set to 20, and the 21st query blocks silently instead of erroring. A rate limiter allows 100 requests per minute; the 101st request in a burst returns 429, but the counter resets one millisecond into the next window and the same client spikes again immediately.

Concurrency boundaries include the plan seat cap, the database connection pool ceiling, the thread pool size, the rate-limit window boundary (fixed vs. sliding), lock contention thresholds, and the queue depth at which consumers fall behind producers. Test by opening one more session than the plan allows and observing eviction behavior. Run pool_size + 1 concurrent queries and measure blocking versus erroring. Fire N requests at the rate limit’s fixed window boundary, then fire N more one millisecond after the reset.

These are the boundaries that hide until traffic scales. The 2025 ITIC/Calyptix SMB Downtime Survey found that 8% of small and mid-size businesses now report downtime costs exceeding $25,000 per hour, and a concurrency ceiling that trips at 3 a.m. is one of the fastest ways to hit that number.

How to Find Boundaries the Spec Skipped

Discovery is more valuable than value substitution. Four questions work against any feature under test:

• What does this feature depend on? Cookies, headers, URLs, request bodies, timers, database columns, connection pools. Every dependency has a limit.
• What’s the limit of each dependency? Read the config file, the schema, the SLA, the cloud provider’s quota page. If the limit isn’t written anywhere, run a load test to find it.
• What happens at exactly that limit, one below, and one above? This is the classic BVA move, applied to infrastructure instead of a form field.
• What happens when the limit changes? A schema migration, a plan upgrade, a config bump. Boundaries move. Tests should move with them.

The boundary is real whether or not someone wrote it down. The tester’s job is to find it before the user does.

Where BVA Fits in Your Test Design

Boundary value testing discovers where a system changes behavior. Equivalence partitioning tells you which of the values between boundaries you can safely skip. Together they compress a giant input space into a small, high-signal test set that catches the failures worth catching.

Two neighbors in the same toolkit make BVA sharper. Equivalence partitioning groups values that behave the same way, telling you which of the values between boundaries you can safely skip. Negative testing generates the bad inputs the requirements never sanctioned, catching the failures BVA doesn’t hunt for. Together, all three compress a giant input space into a small, high-signal test set that catches the failures worth catching.

Map the Boundary Before Your Users Do

The tester who owns hidden boundaries doesn’t test values. They map the places the system changes behavior, then probe each one. The requirements doc is the starting point of boundary analysis, not the whole map.

If your last off-by-one shipped past the test suite, the fix isn’t more test cases; it’s a systematic sweep of the boundaries nobody wrote down. Contact us and we’ll take a look at where they might be hiding in your product.

FAQ

What boundaries should I test besides input ranges?

Test the boundaries the requirements doc doesn’t list: cookie and header size, URL length, request body caps, MTU, DST and month-end transitions, int32 and float precision limits, VARCHAR width across schema versions, pagination first/last/exact-multiple pages, batch runtime caps, connection pool ceilings, rate-limit window edges, and plan seat caps. These are where off-by-one bugs actually ship.

How do you find boundaries that aren't in the requirements?

Run four questions against every feature: what does it depend on, what’s the limit of each dependency, what happens at that limit and just around it, and what happens when the limit changes. Read the config file, the schema, and the cloud provider’s quota page. If a limit isn’t written down, a load test will find it.

What is the difference between boundary value analysis and edge case testing?

Boundary value analysis is numeric and precise; it lives at a measurable threshold like row 999 vs. 1,000. Edge case testing is broader and covers weird states or unusual combinations that may not have a clean numeric edge, like an offline device or a user with zero permissions. Every boundary is an edge case; not every edge case is a boundary.

Why do off-by-one bugs still ship in 2026?

Requirements docs describe the happy input, testers test what’s written, and implicit boundaries only surface under load. Explicit boundaries get automated during development. Implicit ones, like a Lambda runtime cap or a cookie size limit, get discovered by users at 2 a.m. because nobody wrote a test for a limit nobody wrote down.