Information Technology Reference
In-Depth Information
permits a kind of corrective testing, which is different from post-facto
testing.
If a test fails during developer testing, one should try and isolate the
concerned part of the code. Faced with a long list of items to fi x,
developers have a tendency to make changes in many “suspect” areas of
the code simultaneously. It is better to fix one problem at a time, re-test
the fix for correctness, and then take up the next bug. If one changes
code to fix multiple bugs and the re-testing shows that some bugs have
not been fixed, it would be impossible to determine whether a particular
fix is ineffective or a combination of some code change is, in fact,
responsible. Similarly, while fixing a particular problem, a useful strategy
would be to make only one code change at a time for a particular problem.
Black-Box and White-Box Testing
Black-box testing is based on the knowledge gathered from the require-
ments and functionality documentation. It is behavioral in nature. Black-
box testing is concerned with only testing the specification; it cannot
guarantee that all parts of the source code have been tested for faults.
White-box testing, on the other hand, is based on the knowledge of an
application's internals — the source code — and is thus structural in
nature. Because white-box testing is concerned only with testing the
software product, it cannot guarantee that the nonfunctional specification
has been implemented.
It is not easy to classify testing as one kind or another. What may be
considered black-box by one person may be considered white-box by
another. To take an example, test-driving a car may be considered black-
box testing by the quality control group that checks on the engine
performance parameters. However, it might be considered white-box by
the group that deals with the temperature, fuel injection, and valve and
piston pressure within the engine block.
White-box testing is more expensive. It requires the product to be
ready before the tests can be planned, and uses a more tedious and
lengthy process to ascertain the right test cases and determine the cor-
rectness of the software. The “whiter” you get in testing, the mor e
expensive it becomes. Thus, it is better to start the QA process with black-
box tests. This can be done as soon as the requirements specification
document is available. White-box planning can follow as software modules
are developed and the respective black-box tests have been successful.
The ramifications of test failure are also different with black- and white-
box testing. A black-box test failure may not require the repetition of all
the white-box tests. The reverse, however, is not true. If software is
