Boundary Value Testing

Definition

Boundary value testing is a gray-box unit and function testing technique for identifying test cases designed for eliciting failures associated with boundary values.

Discussion

Boundary testing assumes that defects are more likely to occur where data or objects are discontinuous rather than where data or objects are far from such boundaries. Traditional boundary value testing typically involved either boundaries in one dimensional numerical data types such as integers, floating point numbers, or real numbers or else the end points of enumeration types. With such traditional numerical data types, the negative and positive numbers would be bounded by the following three boundary values: the most negative number, 0, and the most positive number. Boundary value testing would create a test case for each of the following values:

• The minimum negative number (a boundary value)
• A negative number near the minimum negative number
• A typical negative number
• A slightly negative number near zero
• Zero (a boundary value)
• A slightly positive number
• A typical positive number
• A positive number near the maximum
• The maximum positive number (a boundary value)

Boundary value testing is greatly impacted by the use of object-orientation. Traditional simple numerical data types are rarely used, except to build more complex object abstractions. It is typically much more difficult to identify the boundary conditions of such objects that may have numerous attributes. Modern boundary value testing typically involves decomposing the complete state space of an interaction (including input parameters, output values, attributes, etc.) into a set of disjoint regions in a multidimensional space, each axis of which represents a single object type involved in the interaction. Often, unit testers base their decisions on the state models of the classes involved.

Objectives

The typical objectives of boundary value testing are to:

• Provide more complete test coverage than equivalence set testing.
• Produce test cases that are likely to elicit failures because defects tend to cluster around boundary values.

Preconditions

Boundary value testing can typically begin when the following preconditions hold:

• The tester(s) has been trained in boundary value testing.
• The item under test has been:
  • Specified (use case path for testing application) or
  • Designed (interface and responsibilities for software component or class).

Completion Criteria

Boundary value testing is typically complete if the following postconditions hold:

• A set of test cases exists for each discontinuity (if any) in each:
  • Input parameter
  • Output value
  • Attribute
  • Collaborator
  • Output value received from a collaborator
  • Exception thrown
  • Exception handled
• Whereby each set of test cases includes one test case for each of the following conditions:
  • Far from the boundary value on one side
  • Near the boundary on one side
  • On the boundary
  • Near the boundary on the other side
  • Far from the boundary on the other side

Steps

During boundary value testing, the unit and functional testers typically perform the following steps (in the following decreasing order of importance):

• Identify all object and data types involved in an interaction.
• Identify all that have state models.
• Using the state models and any assertions involving the interaction, identify all relevant boundary values.
• To identify common failures caused by individual boundaries:
  • Create a test case for each boundary value.
  • Create two test cases near each boundary value, one on each side of the boundary.
• Create one test case near the middle of each "volume" bounded by the boundary values.
• Create a test case simultaneously using as many of the boundary values as is practical to cause rare failures caused by the interaction of multiple boundaries.

Work Products

Boundary value testing typically results in the following work products:

• Test suites containing five test cases for each operation.

Limitations

Boundary value testing is typically subject to the following limitations:

• In order to minimize the number of test cases, this testing technique assumes that the boundary values identified from the specification and design are the only boundary values. However, this assumption is based on the assumption that the implementation of the class conforms to its specification and design. If the implementation does not match the design as specified (which it often does not if a defect exists), then additional boundaries will exist due to the defects.
• Instantiating an object that is either on or near a boundary between regions is often nontrivial.

Guidelines

• Use equivalence set testing (and error guessing) augment equivalence set testing with boundary value testing.
• Do not only consider the boundaries caused by the state of the item under test or attributes based on simple data types.