Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Can anybody tell me what equivalence and boundary testing are?

15 views
Skip to first unread message

Adrian Rutter

unread,
Sep 15, 1999, 3:00:00 AM9/15/99
to
Please.


Michael Bolton

unread,
Sep 15, 1999, 3:00:00 AM9/15/99
to
Adrian Rutter wrote in message
<582726921B60D111A21600805F85B15E22450B@TAXSOFT_COMMS>...
>Please. (Can anybody tell me what equivalence and boundary testing are?)


Sure. Let's start with boundary conditions. A boundary is the line between
which some criterion or another changes, usually but not always between
valid and invalid data. A field that is designed to accept a number from 0
to 99 has the following associated boundaries:

- between 0 and -1 (0 is valid, -1 is not)
- between 99 and 100 (99 is valid, 100 is not)
- between 0 and 1 (though both are valid, the boundary between 0 and 1 is
often interesting)
- between 9 and 10 (though both are valid, the boundary between 1-digit and
2-digit numbers is often interesting)

The reason that these boundaries are important has to do with the way
program logic works. Computer programs check for valid data by comparing
the data you enter with specific values. There are a number of comparison
operators and they can be easy to screw up. For example, there's a big
difference between "greater than zero" and "greater than or equal to zero".
Not only is it easy to mistake one for the other in your mind, but the
symbols for these comparisons look similar to each other too ( >0 and >=0).
It's also easy to confuse greater-than and less-than; just a slip of the
fingers or a blurred eye can change < to > (less-than to greater-than). For
this reason, it's most useful to design tests around the boundary values;
you're most likely to trap a coding error there.

"Equivalence" refers to values that are on the same side of a boundary. We
use equivalence classes to group test cases that we expect to return the
same result. This allows us to reduce the number of tests that we have to
run. For example, in our 0-99 input model, numbers between 0 and 99
(inclusive) are equivalent; they're all valid numbers on the same side of
the boundaries between the upper and lower limits. Numbers greater than 99
are equivalent; they're invalid numbers, above the upper limit. We don't
want to try each and every valid number between 0 and 99; that would take
plenty of time. We especially don't want to try each and every invalid
number, since the set of all numbers that is less than 0 and greater than 99
is an infinitely large set. Instead, we try a few values from the same
equivalence classes. If the programmer has got the logic wrong and mixed up
"greater than 100" and "less than 100", you'll get the same result whether
you test 14, 28, 78, or 99; each test will fail, and each should give you
an equivalent failure. You'll get the same result when you test 101, 102,
108, 125, or 10294753; even though the programmer has screwed up the
checking below the boundary, each of these numbers will be rejected as
invalid data, since each is equivalently inappropriate.

The idea here is to try to figure out inputs that are representative of
their equivalence classes. "Valid data" -- 0 to 99 -- is an equivalence
class. "Invalid data"--less than zero or greater than 99--is another
equivalence class. 0-9 is an equivalence class--valid, single-digit
numbers. 10-99 is an equivalence class--valid, two-digit numbers. The best
way to test efficiently is to choose inputs that are near the boundaries,
and to test as few numbers as possible that are in the same equivalence
class. So, in our example, the essential values to test would include -1,
0, 1, 9, 10, 98, 99, and 100. 97 is less interesting because we figure that
if 99 and 98 (both valid numbers) work properly, 97 is highly likely to work
too; the same for 96 and everything else down to the next boundary, which we
reckoned to be 10 -- the boundary between two-digit and one-digit numbers.

Now, there's always a possibility that the program will reject 64 while
accepting 63 and 65, but you'd have to figure that to be a wild coincidence.
The probability is that errors will happen near the boundaries and will
happen for a whole class of numbers, rather than just one.

There are other kinds of boundaries; between F and G is a boundary (one is a
valid hexadecimal digit; the other is not). '/' and '0' are on either side
of a boundary; former's ASCII code is 47, one less than the latter's ASCII
code of 48. 255 and 256 straddle a boundary; the former is the largest
unsigned value that you can hold in a single byte of data; the latter is one
more than that. (This is a problem because when you add 1 to 255, you can
get 0 if the programmer hasn't accounted for overflowing the byte properly.)

I'm beginning to sound like a broken record in this newsgroup: Testing
Computer Software by Cem Kaner is a great book. It explains boundaries and
equivalence classes in a clear, vigourous, and entirely understandable way.
Pick up a copy; if your company won't buy it for you, get it yourself and
keep it.

---Michael B.

Visit my Web site at http://www.michaelbolton.net. Read what you like and
complain about the rest; all feedback and consulting job offers welcome.


Datasdream

unread,
Sep 17, 1999, 3:00:00 AM9/17/99
to
A few addtions to the 0-99 domain.

The boundaries are at 0 and 99. Correct.
So invalids testing would contain -1 and 100. Correct.
However there can be soome very inertesting testing done with a -0.
While the real world would use a -0 as a 0 computer programs are not always
consistant inhow they use it.

Just a small addition. In the grey boundary zone.

Software testing / Quality assurance
Roger Richardson

0 new messages