Boundary value analysis

If the system behaviour changes as soon as the value of a parameter exceeds a particular boundary, this is called a ‘ boundary value’.

The following example demonstrates this: 

In this example, there are 3 equivalence classes for the age parameter. The values of 18 and 55 are the boundaries for this parameter. Both boundaries belong in this case to the middle equivalence class of "standard loan", as illustrated in below figure.

In practice, it appears that many faults are connected with boundaries. Usually these are simply ‘sloppy programming mistakes’ in which the programmer, for example, has accidentally programmed a “>” instead of a “≥”, or a “=” instead of a “≥”. In the above example, somewhere in the code, the condition "IF age ≤ 18 THEN …" could have been programmed accidentally. In that case, the age of 18 could suddenly be allocated to the first equivalence class ("Refuse loan") instead of to the middle one ("Standard loan"). 

Apart from in the equivalence classes, boundaries also often occur in the coverage of conditions and decision points. For example, in the lending system the following condition could be defined:

 IF ( loan sum > salary ) THEN …

Here, the “loan sum” is the parameter with the boundary of “salary”.
The testing of whether the boundary values have been allocated to the appropriate equivalence class (or outcome of the condition) is a separate test goal that is achieved by means of “ boundary value analysis”.
The technique for carrying out boundary value analysis is simple in the extreme:

• Determine the boundaries of the relevant equivalence class or condition
• Define the following 3 test situations: exactly on the boundary, directly above it, directly below it.

This way of elaborating 3 test situations per boundary value is called the Normal variation. There is also a (S)light variant of boundary value analysis, with which only 2 test situations are tested: the boundary itself plus the adjacent values in the other equivalence class.

If boundary value analysis has not been opted for explicitly, experienced testers will often intuitively apply the slight variant. Indeed, if it is a requirement to test a value from both equivalence classes (above and below the boundary), then “exactly on” and “adjacent to” the boundary value can be selected without any extra effort.

A disadvantage of the slight variant is that this will not uncover certain faults that are found using standard boundary value analysis. An example of this is the previously mentioned fault, in which a “=” has been programmed instead of a “≥”.

Boundary value analysis is not always applicable to equivalence classes or conditions. Boundaries are not always present. Take, for example, the parameter “Gender” with the values (and therefore equivalence classes) of “M” and “F”. There is no such thing as a boundary between the “M” and the “F”. This applies also, for example, to all those parameters in a system that belong to ‘codes’ and ‘types’.

Boundary value analysis is not only applicable to the input side of a system, but also to the output side. Suppose that a sales quote page should contain a maximum of 10 lines. This is then tested using boundary value analysis by printing out an offer with 9 lines, with 10 lines (all the lines on one page) and with 11 lines (eleventh line on second page). 

See the following animation for a more detailed explanation: