Boundary value analysis

Boundary value analysis (BVA) tests the values at the edges of each input range, because that is where developers make mistakes: > instead of >=, < 60 instead of <= 60, a loop that runs one time too many. It is normally applied after equivalence partitioning, which identifies the ranges, and BVA then picks the exact values on and around each edge.

Example: age 18 to 60 accepted

A sign-up form accepts ages 18 to 60 inclusive.

Two-value BVA (the boundary and its nearest neighbor outside the range):

Input	Expected
17	Rejected
18	Accepted
60	Accepted
61	Rejected

Three-value BVA adds the neighbor on the inside of each boundary:

Input	Expected
17, 18, 19	Rejected, Accepted, Accepted
59, 60, 61	Accepted, Accepted, Rejected

Six tests instead of 43 possible valid ages, and these six catch the common comparison mistakes. If the code says age > 18, the test with 18 fails. If it says age < 60, the test with 60 fails.

Beyond numeric ranges

Boundaries exist wherever there is a limit:

• Length: a username of 3 to 20 characters means testing 2, 3, 20 and 21 characters.
• Dates and times: a link valid for 30 minutes means testing at 29:59, 30:00 and 30:01. Also check midnight, month ends and leap days where relevant.
• Collections: an empty cart, one item, and the maximum allowed items plus one.
• Money: $99.99, $100.00 and $100.01 for a “free shipping from $100” rule.
• Technical limits: maximum file size, integer overflow, page size in paginated APIs.

Common mistakes

• Testing only the valid side. 17 and 61 matter as much as 18 and 60.
• Assuming the boundary. “Up to 60” might mean 60 is included or not. Ask, and record the answer in the acceptance criteria.
• Ignoring type and precision. If the field accepts decimals, the value just below 18 might be 17.99, not 17.
• Forgetting the hidden boundaries. A database column or an API may impose a different limit than the UI. Test the limits at each layer.