Boundary value analysis and equivalence partitioning

Equivalence partitioning: test one, cover many

Most inputs fall into groups that behave the same way. If a field accepts 1 to 100, then 5, 40, and 88 all behave identically. Testing all three wastes time.

Equivalence partitioning splits inputs into partitions, then tests one value from each. You cover the behaviour without the repetition.

• Valid partition: any number from 1 to 100.
• Invalid partition below range: 0 and lower.
• Invalid partition above range: 101 and higher.

Pick one value from each, such as 50, minus 4, and 250. Three tests represent the whole input space.

Boundary value analysis: test the edges

Bugs cluster at the edges of a range. Off-by-one errors, wrong comparison signs, and bad limits all show up there. Boundary value analysis targets exactly those points.

For a field that accepts 1 to 100, you test the values right around each boundary:

• Lower boundary: 0 (invalid), 1 (valid), 2 (valid).
• Upper boundary: 99 (valid), 100 (valid), 101 (invalid).

Those six values catch the classic mistake where a developer writes greater-than instead of greater-than-or-equal, so 100 gets wrongly rejected.

Equivalence partitioning cuts the number of tests. Boundary value analysis aims the ones you keep at the riskiest spots.

Using both together

The two techniques are a pair. Partitioning tells you the groups. Boundary analysis tells you which exact values inside and around those groups deserve a test.

Combine them for a field like age 18 to 65. You test one middle value such as 40, then the edges 17, 18, 65, and 66. Five tests give strong coverage of a rule that could otherwise take dozens.

This design thinking sits at the heart of solid manual testing, and it carries straight into a test automation framework and API and contract testing, where the same edge values become fast automated checks. The ISTQB foundation syllabus documents both techniques in detail.

The honest caveat

These techniques assume clean, ordered ranges. Real inputs are messier. Dates, currencies, and text fields have edges that a simple number line will not show, such as a leap day or a zero-width space.

So we treat boundary analysis as a strong starting point, then add exploratory testing for the odd inputs no formula predicts. That mix is how we keep coverage high without drowning teams in cases across e-commerce and SaaS products.

If your test suite feels large but bugs still slip through the edges, the design may be the issue. A free 30-minute testing audit is a quick way to check where your input coverage really stands.