Boundary Value Testing

Boundary value testing is an extension of equivalence class testing. But rather than testing just one of the values in the class you test the upper and lower values of the class as well as the value above and below that value. Since most programs have a significant behavior change at boundaries it is always good to make sure that you have the correct behavior at the boundaries. This is more thorough than equivalence class testing and will find a lot of the off-by-one errors in the product.

Some steps to setup Boundary value tests.

1. Identify the equivalence classes.
2. Identify the boundaries of each equivalence class.
3. For each boundary, write one test case for one unit below the boundary, on the boundary, and one unit above the boundary.
4. The one unit above and below may create duplicate tests. If this is the case just run the test once, and note the results.

Some of the positive aspects of this type of testing are:

1. You focus on problematic areas in the system.
2. You cover both valid and invalid cases.
3. You have a relatively small test set.
4. You can use this style of testing with non-functional requirements like performance and capacity.

There is only one problem with Boundary Testing is that in some cases it is hard to come up with appropriate boundary values.

Boundary value testing is rather simple and is one of the few testing strategies that has more good things to say about it then bad.

Equivalence Class Testing

Today I thought I would talk about Equivalence Class Testing.

Equivalence Class Testing is when you create sets of input that have equivalent expected behavior. You do this until all possible inputs show up in one of the groupings. Now when you test one item from each of the inputs you should be covering all the possible inputs in that grouping.

Some types of inputs lend themselves really well to this type of testing – the first is a range of values. You break it down into values within the valid range, invalid values above the valid range and invalid values below the valid range. Lets have an example to better illustrate what I am trying to describe. We are going to test the appointment-making part of the program. An appointment has four fields:

1. Time
2. Day
3. Month
4. Year

Lets look at the month input field. Depending on how it is implemented it could take valid values from 1-12 or it could take the months in a string format. Lets look at the input of values from 1-12 and what equivalence classes world be necessary to test this input.

• valid range of 1-12
• invalid range below the valid range <1
• invalid range above the valid range >12

If the input was a string you would end up with two sets. One that had the valid inputs in it and one that had every thing else you could think to put in it.

So along with the month input you would also have a day, year, and time input. The program is written in such a way that they all have to be tested at the same time. So you list all the groupings for all the other inputs fields and test them at the same time. You will notice that you can test most of the valid test cases at the same time, but you will have to test the error cases one field at a time so you can make sure the error is handled appropriately.

This kind of testing will allow you to keep the number of test cases small, and you could use this type of testing at any level of testing from unit all the way up to acceptance testing. One of the limiting factors of this type of testing is that it assumes identical behavior for all items in a grouping. This is best suited to testing programs where inputs are within ranges or values in sets.