Testing the Product Specification

If you're fortunate enough to be involved on the project early and have access to a preliminary specification, more power to you. Finding bugs at this stage can potentially save your project huge amounts of time and money.

If you're fortunate enough to be involved on the
project early and have access to a preliminary specification, more power to you.
Finding bugs at this stage can potentially save your project huge amounts of time
and money.

Testing the product spec isn't something that all software testers have the
luxury of doing. Sometimes you might come into a project midway through the
development cycle after the specification is written and the coding started.
If that's the case, don't worryyou can still use the techniques overviewed
here to test the final specification.

Black-Box and White-Box Testing

Two terms that software testers use to describe how they approach their testing
are black-box testing and white-box testing. Figure
1 shows the difference between the two approaches. In black-box testing,
the tester only knows what the software is supposed to dohe can't look
in the box to see how it operates. If he types in a certain input, he gets a
certain output. He doesn't know how or why it happens, just that it does.

With black-box testing, the software tester doesn't know the details of
how the software works.

Think about the Windows Calculator. If you type 3.14159 and press
the sqrt button, you get 1.772453102341. With black-box testing, it doesn't
matter what gyrations the software goes through to compute the square root of
pi. It just does it. As a software tester, you can verify the result on another
"certified" calculator and determine if the Windows Calculator is
functioning correctly.

In white-box testing (sometimes called clear-box testing), the software
tester has access to the program's code and can examine it for clues to help
him with his testinghe can see inside the box. Based on what he sees,
the tester may determine that certain numbers are more or less likely to fail
and can tailor his testing based on that information.

NOTE

There is a risk to white-box testing. It's very easy to become biased and
fail to objectively test the software because you might tailor the tests to
match the code's operation.