Boundary value analysis, generated

Boundary value analysis is a black-box test design technique that tests the values at the edges of an equivalence partition. If a field accepts ages from 18 to 60, the interesting values are not 30 or 45 but 17, 18, 60 and 61, because that is where a developer chooses between less-than and less-than-or-equal, and where that choice is most often wrong.

It works on any input with an ordered range: numbers, dates, string lengths, file sizes, quantities in a basket, the number of retries before a lockout. It is usually applied alongside equivalence partitioning, which divides the input into ranges, while boundary value analysis tests where those ranges meet.

Two-value analysis tests each boundary value and its closest neighbour on the other side. For 18 to 60 that is 17, 18, 60 and 61: four tests. It catches a comparison operator pointing the wrong way, which is the most common boundary defect.

Three-value analysis adds the closest neighbour on the inside: 17, 18, 19 and 59, 60, 61. The extra values catch a different defect, a boundary coded as equality. Take a field with only a minimum, "at least 18". A check written as "age == 18" instead of "age >= 18" accepts 18 and rejects 17, exactly as two-value analysis expects, and only 19 reveals that it rejects every valid age above the minimum. The ISTQB Foundation syllabus describes both variants.

Requirements state limits in different ways, and the boundaries move with the wording. "At least 1" and "more than 0" describe the same whole-number field: 0 is invalid and 1 is the lowest valid value. The generator works from the lowest and highest valid values rather than from the numbers in the sentence, so both wordings produce the same tests.

When the requirement is ambiguous ("between 1 and 10"), that ambiguity is the first defect to raise. Ask whether 1 and 10 are included before writing a single test, because the developer had to decide too, and may have decided differently.

The step is the smallest change the system recognises. For whole numbers it is 1. For a price in rupees, dollars or euros it is usually 0.01, so the boundaries of a 0.01 to 999.99 range are 0.00, 0.01, 999.99 and 1000.00. Testing 1000 instead of 999.99 plus one step would miss a defect that only appears between 999.99 and 1000.00.

Choose the step from the data type, not the screen. A field that displays two decimal places but stores four has a step of 0.0001, and a rounding defect can hide between what the user sees and what the database holds.

Every field has boundaries nobody wrote down. A text field has a maximum length in the database even when the form has none. A number field has the limits of its data type, such as 2,147,483,647 for a 32-bit signed integer. A date has the earliest and latest date the system can store. Test these implicit boundaries too: they are where overflow, truncation and silent rounding defects live.

Length boundaries also depend on how length is counted. 255 characters of plain text and 255 characters of emoji are different sizes in a database. The edge case string generator produces strings for exactly that test.