Boundary value analysis

Boundary value analysis is a test design technique: for any input with limits — a rating from 0 to 10, a page size up to 100, a name up to 50 characters — test the values exactly at each limit and just either side of it. Bugs cluster at boundaries because that is where comparisons are written, and < versus <= is easy to get wrong.

How it works

For a range of 0 to 10 inclusive, the interesting inputs are −1, 0, 1, 9, 10 and 11: the two limits, their inside neighbours and their outside neighbours. The outside values should be rejected — usually with 400 or 422 — and the inside ones accepted. The same applies to lengths, dates, counts and sizes.

The misconception

That testing a typical value plus one invalid value covers the rule. A test with 5 and 999 passes against code that accepts 10.5, rejects 10 or allows 11. Only the values at the edge distinguish a correct boundary from a nearly correct one.

Try it here

PUT /movies/v1/movies/{id}/rating accepts 0 to 10 inclusive — try −1, 0, 10 and 11 — and the Starfleet API rejects a warp factor above 9.9 on PUT /starfleet/v1/ships/{id}/warp.

Sources

Other terms

Mock API — A stand-in for a real API that returns realistic responses without the real system behind it.
API sandbox — An isolated copy of an API where calls have no real-world effect and data can be reset.
Mocks, stubs and fakes — Three kinds of test double — stand-ins for a real dependency — that differ in what they do and what they check.
Test fixture — The known data and state a test starts from, set up the same way on every run.
Contract testing — Testing that an API and its consumers agree on the shape of requests and responses, without running them together.
Smoke testing — A small, fast set of checks that the most important paths work at all, run before anything more thorough.

All glossary terms · Testing techniques · All 39 mock REST APIs

Last updated 16 October 2026