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 =).
Defining
the Tests
To determine the tests for
this method, first identify valid and invalid input and output conditions for a
given function.
Then, identify the tests
for situations at each boundary. For
example, one test each for >, =, <, using the first value in the >
range, the value that is equal to the boundary, and the first value in the <
range.
Boundary conditions do not
need to focus only on values or ranges, but can be identified for many other
boundary situations as well, such as end of page, (i.e., identify tests for
production of output that is one line less than the end of page, exactly to the
end of page, and one line over the end of page). The tester needs to identify as many situations
as possible, the list of Common Extreme Test Conditions may help with this
process:
COMMON EXTREME TEST
CONDITIONS
- zero or negative values
- zero or one transaction
- empty files
- missing files (file name not resolved or access denied)
- multiple updates of one file
- full, empty, or missing tables
- widow headings (i.e., headings printed on pages with no details or totals)
- table entries missing
- subscripts out of bounds
- sequencing errors
- missing or incorrect parameters or message formats
- concurrent access of a file
- file space overflow
EXAMPLE
OF BOUNDARY VALUE ANALYSIS
Function
to be Tested
For a function called
billing, the following specifications are defined:
- Generate a bill for accounts with a balance owed > 0
- Generate a statement for accounts with a balance owed < 0 (credit)
- For accounts with a balance owed > 0
- place amounts for which the run date is < 30 days from the date of service in the current total
- place amounts for which the run date is = or > 30 days, but < or = 60 days, from the date of service, in the 30 to 60 day total
- place amounts for which the run date is > 60 days, but < or = 90 days, from the date of service, in the 61 to 90 day total
- place amounts for which the run date is > 90 days, from the date of service, in the 91 days and over total
- For accounts with a balance owed > or = $10.00, for which the run date is = or > 30 days from the date of service, calculate a $3.00 or 1% late fee, whichever is greater
Input
and Output Conditions
Identify the input, (i.e.,
information is supplied to the function) and output, (i.e., information is
produced by the function) conditions for the function.
The input conditions are
identified as:
- balance owed
- balance owed for late fee
The output conditions are
identified as:
- age of amounts
- age of amounts for late fee
- calculation for late fee
Defining
Tests
Define tests for the
boundary situations for each of the input and output conditions. For example:
Balance
Owed
01. > 0
02. = 0
03. < 0
Age
of Amounts
balance owed > 0 and
04. run date - date of service = 00
05. run date - date of service = 29
06. run date - date of service = 30
07. run date - date of service = 31
08. run date - date of service = 59
09. run date - date of service = 60
10. run date - date of service = 61
11. run date - date of service = 89
12. run date - date of service = 90
13. run date - date of service = 91
Balance
Owed for Late Fee
run date - date of service
> 30 and
14. balance owed = $9.99
15. balance owed = $10.00
16. balance owed = $10.01
Age
of Amount for Late Fee
balance owed > $10.00
and
17. run date - date of service = 29
18. run date - date of service = 30
19. run date - date of service = 31
Calculation
for Late Fee
balance owed > $10.00,
run date - date of service > 30 and
20. 1% late fee < $3.00
21. 1% late fee = $3.00
22. 1% late fee > $3.00
