Testing the Product Specification
- Testing the Product Specification
- Static and Dynamic Testing
- About This Article
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.
){kind=link}
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.