Boundary testing

Boundary testing focuses on the edges of what your software will accept. Instead of testing random values, you systematically check what happens right at and around the limits of valid inputs. It's where you find those sneaky off-by-one errors that plague developers.

Let's test an age verification system for a financial app that accepts users between 18 and 65 years old. 

You'd test:

Each boundary needs validation to ensure the system accepts or rejects values correctly.

Boundaries are where systems often break. A registration form might accept 50 characters for a name field, but what happens at character 51? Does your tax calculator handle amounts over $999,999.99? Boundary testing catches these issues before users discover them in production, where they could corrupt data or crash your system.

Finding every boundary in a complex system is tough—they're not always obvious like minimum and maximum values. Some hide in business rules or emerge from combinations of different limits. 

Plus, passing boundary tests doesn't guarantee your system works correctly between the boundaries. That's why you need to combine boundary testing with other techniques to ensure thorough coverage.

Definition: A technique that tests behaviour right around a defined threshold by checking the value just below the boundary, the value on it, and the value just above. It reflects how a system is meant to operate at its limits, not unusual or invented inputs. Also referred to as Boundary Value Analysis (BVA).

So what? The values either side of a threshold are a normal function of a system, so testing them is part of confirming intended behaviour rather than an optional extra.

Examples: If something triggers at a threshold of ten, testing 9.99 (nothing happens), 10 (it triggers, if ten is inclusive), and just above ten; asking whether a date boundary is inclusive or exclusive (does it act on day 30, day 31, or day 29?).