Boundary values

Approach Coverage based - data
Test variety

Primarily functionality, also applicable in other test varieties

Test basis Almost all kinds

If the system behaviour changes as soon as the value of a parameter exceeds a particular boundary, this is called a ‘ boundary value’. 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 “≥”.
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’.
See the following animation for a more detailed explanation: