Overview
Boundary value analysis is a software testing design technique to determine test cases covering off-by-one errors. The boundaries of software component input ranges are areas of frequent problems.
Contents
- Introduction
- What is Boundary Value Analysis?
- Purpose
- Applying Boundary Value Analysis
- Performing Boundary Value Analysis
Introduction
Boundary value analysis is the technique of making sure that the behaviour of the system is predictable for the input and output boundary conditions. The reason why boundary conditions are very important for testing is that defects could be introduced at the boundaries very easily.
"Input should be greater than equal to 10 and less than 50"
Probably you will write that something like:
if (input >=10 AND input <50) then
do something
else
do something else.
So, according to this, the input values from 10 to 49 are valid, but if you make a mistake in specifying the conditions, the following things can happen:
input >10 AND input Input value 10 in is invalid now.
input <=10 AND input Input value 9 is valid now.
input >=10 AND input Input value 50 is valid now
input >=10 AND input >50 -----> Input value 49 is invalid now
Because it is very easy to introduce defects at boundaries, boundary values are important. So for the above example, at the minimum we should have the following test cases for boundaries 9, 10, 11 and 48, 49, 50
As a general rule, if you have any input field it should be tested with the following set of data at the minimum.
lower_boundary - 1, lower_boundary, lower_boundary + 1 and upper_boundary - 1, upper_boundary, upper_boundary + 1
What is Boundary Value Analysis?
Boundary value analysis is a methodology for designing test cases that concentrates the software testing effort on cases near the limits of valid ranges. Boundary value analysis is a method which refines equivalence partitioning. Boundary value analysis generates test cases that highlight errors better than equivalence partitioning.
The trick is to concentrate software testing efforts at the extreme ends of the equivalence classes. At those points when the input values change from valid to invalid, errors are most likely to occur. As well, boundary value analysis broadens the portions of the business requirement document used to generate tests. Unlike equivalence partitioning, it takes into account the output specifications when deriving test cases.
Purpose
The purpose of boundary value analysis is to concentrate the testing effort on error prone areas by accurately pinpointing the boundaries of conditions (e.g., a programmer may specify >, when the requirement states > or =).
Applying Boundary Value Analysis
To set up boundary value analysis test cases you first have to determine which boundaries you have at the interface of a software component. This has to be done by applying the equivalence partitioning technique. Boundary value analysis and equivalence partitioning are inevitably linked together. For the example of the month in a date you would have the following partitions:
... -2 -1 0 1.............. 12 13 14 15.....
--------------|-------------------|---------------------
Invalid partition 1 valid partition invalid partition 2
Applying boundary value analysis, you now must select a test case at each side of the boundary between two partitions. In the above example this would be 0 and 1 for the lower boundary as well as 12 and 13 for the upper boundary. Each of these pairs consists of a "clean" and a "dirty" test case. A "clean" test case should give you a valid operation result of your program. A "dirty" test case should lead to a correct and specified input error treatment such as the limiting of values, the usage of a substitute value, or in the case of a program with a user interface, it has to lead to a warning and a request to enter correct data. The boundary value analysis can have 6 test cases. n, n-1, n+1 for the upper limit and n, n-1, n+1 for the lower limit.
A further set of boundaries has to be considered when you set up your test cases. A solid testing strategy also has to consider the natural boundaries of the data types used in the program. If you are working with signed values this is especially the range around zero (-1, 0, +1). Similar to the typical range check faults, programmers tend to have weaknesses in their programs in this range. E.g. this could be a division by zero problem where a zero value may occur although the programmer always thought the range started at 1. It could be a sign problem when a value turns out to be negative in some rare cases, although the programmer always expected it to be positive. Even if this critical natural boundary is clearly within an equivalence partition it should lead to additional test cases checking the range around zero. A further natural boundary is the natural lower and upper limit of the data type itself. E.g. an unsigned 8-bit value has the range of 0 to 255. A good test strategy would also check how the program reacts at an input of -1 and 0 as well as 255 and 256.
The tendency is to relate boundary value analysis more to the so called black box testing, which is strictly checking a software component at its interfaces, without consideration of internal structures of the software. But looking closer at the subject, there are cases where it applies also to white box testing.
After determining the necessary test cases with equivalence partitioning and subsequent boundary value analysis, it is necessary to define the combinations of the test cases when there are multiple inputs to a software component.
Performing Boundary Value Analysis
There are two steps:
- Identify the equivalence classes.
- Design test cases.
Step 1: Identify the equivalence classes
Follow the same rules you used in equivalence partitioning. However, consider the output specifications as well. For example, if the output specifications for the inventory system stated that a report on inventory should indicate a total quantity for all products no greater than 999,999, then you'd add the following classes to the ones you found previously:
The valid class (0 < = total quantity on hand < = 999,999)
The invalid class (total quantity on hand <0)
The invalid class (total quantity on hand> 999,999)
Step 2: Design test cases
In this step, you derive test cases from the equivalence classes. The process is similar to that of equivalence partitioning but the rules for designing test cases differ. With equivalence partitioning, you may select any test case within a range and any on either side of it with boundary analysis, you focus your attention on cases close to the edges of the range.