Boundary Value Analysis: Stop Off-By-One Errors Cold

Previously in this course, we explored Equivalence Partitioning to group inputs into logical sets. While that helps us reduce the number of tests we write, it often glosses over the most dangerous part of any input range: the edges.

In software engineering, bugs rarely hide in the middle of a range. If a function is supposed to accept ages 18 to 65, nobody accidentally codes "42" to fail. They accidentally code "17" or "18" incorrectly. This is where boundary value analysis comes in—a technique focused specifically on the points where system behavior changes.

The Physics of Boundaries

When you define a range—say, a discount applied to orders between $100 and $500—you are creating a "decision boundary." At the value $99.99, the result is no discount. At $100.00, it is discounted.

Because programmers often use comparison operators like < instead of <= (or vice versa), these transition points are prime real estate for off-by-one errors.

To perform effective input testing, you must test the three critical points for every boundary:

1. The Boundary itself: The exact value where the rule changes.
2. Just below the boundary: The last value that should result in the "previous" outcome.
3. Just above the boundary: The first value that should result in the "new" outcome.

Worked Example: The "Shipping Fee" Logic

Let’s look at a snippet of our project code. We are writing a simple function that calculates a shipping fee based on order weight.

JAVASCRIPT
// Rules: 
// Weight 0-10kg: $5 flat fee
// Weight 10.01-50kg: $10 flat fee
// Weight > 50kg: $20 flat fee

function calculateShipping(weight) {
    if (weight <= 10) {
        return 5;
    } else if (weight <= 50) {
        return 10;
    } else {
        return 20;
    }
}

If we use boundary value analysis, we don't just test "5" or "25." We test the edges:

If a developer mistakenly wrote if (weight < 10), the input 10 would incorrectly return $10 instead of $5. That is a classic off-by-one error caught instantly by checking the boundary.

Hands-on Exercise

In your current project repository, find a function that accepts a numeric input or a range. It could be a simple age validator or an orderQuantity check.

1. Identify the lower and upper bounds of your logic.
2. Write down the 3 test values for each boundary (the boundary, the value -0.01, and the value +0.01).
3. If you haven't yet, implement these tests in a small script or test file.

Hint: If you are working on a web form, consider how your client-side validation might differ from server-side logic.

Common Pitfalls

• The "One Value" Trap: Many beginners test only the boundary value itself. If you only test 10, you might miss that 10.01 is being handled by the wrong branch. Always test the "step" across the threshold.
• Ignoring Data Types: If your logic handles integers, don't forget that boundaries in programming often involve data type limits (e.g., the maximum integer size in your language).
• Missing Implicit Boundaries: Sometimes a boundary isn't stated in the requirements but exists in the code (e.g., an array index 0 vs array.length - 1). If you aren't sure where the boundary is, look at the conditional statements in your code—they are the source of truth for your test cases.

FAQ

Q: Is boundary value analysis the same as equivalence partitioning? A: No. Equivalence partitioning chooses a representative value from a range to reduce test volume. Boundary value analysis targets the specific, high-risk points where the logic shifts from one partition to another.

Q: Does this work for non-numeric inputs? A: Yes. For strings, the boundaries are the minimum and maximum lengths (e.g., a password field requiring 8-20 characters). You would test 7, 8, 9, 19, 20, and 21 characters.

Recap

Boundary value analysis is your primary tool for error detection in logic-heavy code. By focusing on the values immediately surrounding your conditional thresholds, you turn vague testing into a scientific process that catches off-by-one errors before they reach production. Remember: if the logic can change at a specific point, you must test that point and its immediate neighbors.

Up next: We will take these findings and learn how to translate them into professional, repeatable documents in "Creating Manual Test Cases."