Boundary Value Analysis

Boundary value analysis is the technique that catches the most common class of software bug — the off-by-one error. When a user enters an age, a price, a date, a page number, a loan amount, or any quantity with a minimum and maximum, the code that checks the range usually fails at the edges, not in the middle. By learning this, you will be able to design test cases that reliably find these defects, which is essential for building reliable AI systems — from validating user input in a loan approval model to checking that a chatbot's response length stays within limits. This skill unlocks further study in Equivalence Partitioning (how to divide inputs into classes), API Testing (testing the boundaries of request parameters), and Property-Based Testing (letting a framework generate edge cases for you).

Think about the last time you filled out an online form that asked for your age. There was probably a rule: you must be between 18 and 60, or between 0 and 120, or something similar. Where do you think most bugs happen? Not for a 30-year-old — that's the safe middle. Bugs happen at 17, 18, 19, and 59, 60, 61. Why? Because the code that checks the boundary uses a comparison like 'age >= 18' or 'age <= 60'. If the programmer accidentally wrote 'age > 18' instead of 'age >= 18', then a person who is exactly 18 is wrongly rejected. If they wrote 'age < 60' instead of 'age <= 60', a person who is 60 is wrongly rejected. These errors are called off-by-one errors, and they are incredibly common because humans naturally think '18 or above' but write '> 18' by mistake. Boundary value analysis is a systematic way to test just below, at, and just above each boundary, so you catch these errors before your users do. It is not about testing every possible value — that would be impossible. It is about testing the few values where defects cluster: the edges.

Imagine you are a security guard at a concert. The rule is that only people who are 18 or older can enter. You stand at the door and check IDs. Where do you pay the most attention? Not to a 30-year-old — that's an easy yes. You watch the people who look like they might be 18, maybe 17, maybe 19. The person who is exactly 18 is the most important to check, because the rule could be '18 or older' or 'over 18' — and the difference matters. So you check the 17-year-old (just below), the 18-year-old (at the boundary), and the 19-year-old (just above). That is boundary value analysis. But the analogy breaks down in one way: as a human guard, you can see the person and use judgment. A computer cannot. It has a line of code that says 'if age >= 18: allow' or 'if age > 18: allow'. The difference between those two is what the boundary test catches. Also, in a real concert, the boundary is a single number. In software, there can be many boundaries — a maximum loan amount, a minimum password length, a maximum file size. Each boundary needs three tests: one below, one at, one above. This is not just for numbers; it works for dates, strings, lists — anywhere there is a range.

Boundary value analysis is a software testing technique where test cases are designed to exercise the values at the edges of an input range — just below, exactly at, and just above each boundary — because defects are most likely to occur there due to off-by-one and comparison errors.

This concept sits inside Software Testing, the parent topic you have notes on. It pairs naturally with Equivalence Partitioning, which divides inputs into classes that behave the same and picks one representative from each. Boundary value analysis goes one step further: within each class, you test the edges. For example, if a valid age is 18–60, equivalence partitioning says test one valid value (e.g., 30) and one invalid value (e.g., 15). Boundary value analysis says test 17, 18, 19, 59, 60, and 61. The two techniques together give you a powerful, systematic way to choose test cases without testing everything. This is a classic topic in the book 'Full Stack Testing' by Gayathri Mohan, which is in your library. It also connects to API Testing: when you test an API that accepts a page number or a record limit, you use boundary value analysis on those parameters. And it leads to Property-Based Testing, where a framework generates random inputs, but even then, boundary values are often worth adding by hand.