In words
What it is, why it matters, and what it is like.
Why am I learning this?
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. For example, imagine building an AI system that approves loans. If the code mistakenly rejects a valid loan amount because it compared 'greater than' instead of 'greater than or equal to', your business loses money. Or consider a chatbot that truncates user responses; if it cuts off one character too early, the meaning is lost. This skill lets you catch these specific defects before they reach your users, ensuring that the systems you build work correctly exactly where people expect them to.
The idea, in plain terms
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.
An analogy
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. A caveat: unlike a human guard who can use judgment, a computer relies on exact code logic, making these edge cases critical.
Definition
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.
Where this sits
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.