If you’ve ever wondered why a tester types exactly 7, 8, 64 and 65 characters into a password field, this note is for you. It’s called boundary value analysis, and it’s one of the most useful test design techniques there is.
The idea is simple: bugs cluster at the edges. A developer writes < instead of <=, a database column is one character shorter than the form allows, a date check forgets about the last day of the month. So instead of testing random values, you test the edges on purpose.
The example: a signup form
Here are the rules for a signup form I tested recently (simplified):
- Password: 8 to 64 characters
- Age: 18 to 120
- Username: 3 to 20 characters, letters and digits only
Step 1: find the partitions
First, split each input into groups that should behave the same. This is called equivalence partitioning. For the password length there are three groups:
- Too short: 0 to 7 characters (invalid)
- Valid: 8 to 64 characters
- Too long: 65 or more (invalid)
Testing one value from each group, say 4, 20 and 100, tells you the rule exists. It doesn’t tell you whether the edges are in the right place.
Step 2: test the edges
Now take every boundary between groups and test the value on each side of it. For the password:
- 7 characters: rejected
- 8 characters: accepted
- 64 characters: accepted
- 65 characters: rejected
Four test cases, and they catch the classic off-by-one bugs on both ends. For age, the same logic gives 17, 18, 120 and 121. For the username, 2, 3, 20 and 21.
Step 3: add the edges nobody wrote down
Requirements rarely list every boundary. A few I always add:
- Empty and only spaces: is “ ” an 8-character password?
- Leading and trailing spaces: are they trimmed before or after counting?
- Multi-byte characters: does “zażółć” count as 6 characters or 10?
- Numbers at the edge of the field type: 0, negative numbers, decimals like 17.9 for age
These implicit boundaries find more bugs than the documented ones, because nobody designed for them.
Two-value or three-value?
What I showed above is two-value boundary analysis: the boundary and its nearest neighbour outside. Three-value analysis also tests the neighbour inside (9 and 63 for the password). For most forms, two values are enough. For money, dates and anything compliance-related, I use three. In banking, an interest rule that fails on the last day of a period is not a bug you want to find in production.
Why this matters beyond forms
Boundaries are everywhere: free shipping from €50, a discount for orders of 10 items or more, a session that expires after 30 minutes, a file upload limit of 5 MB. Wherever there’s a number in a requirement, there are edges to test.
A handful of well-chosen values beats a hundred random ones. That’s what test design is about: not testing more, but testing smarter.
Frequently asked questions.
What is boundary value analysis?
A test design technique that focuses on the values at and around the edges of valid ranges, such as the minimum, the maximum and the values just outside them, because that is where bugs are most likely.
How is it different from equivalence partitioning?
Equivalence partitioning splits inputs into groups that should behave the same and tests one value from each group. Boundary value analysis then tests the edges between those groups. They are usually used together.
Is two-value or three-value boundary analysis better?
Two-value analysis (the boundary and its nearest neighbour outside) is enough for most forms. Three-value analysis adds the neighbour inside and is worth it for money, dates and anything safety- or compliance-related.
