Some traditional white-box testing techniques may also be adapted to conduct black-box testing, such as control-flow and data-flow testing for external functional units instead of for internal executions.
Black-box testing may follow the generic testing process to perform planning, implementation and follow-up. In test planning, main attention is paid to detecting the external functions to test and deriving input conditions to test such functions.
The detected external functions are often associated with some user anticipations, from which both the input and the expected output can be derived to form the test cases.
For instance, for a compiler, the input is source code to be compiled; the output is the resulting object or executable code. Part of the expected behavior is system termination, that is, the compiler should produce some output within a limited time. Another part is that if illegal programs are provided as input, object or executable code will not be generated, and the reason should be given.
Consequently, a collection of programs to be compiled constitutes the test suite, or the collection of test cases. This test suite should characteristically contain both legal and illegal programs to cover the anticipated spectrum of input. The testing purposes may be stated explicitly as exit quality levels or implicitly as the completion of planned test cases.
The main goal of test implementation at the time of black-box testing is to monitor the external behavior, to assure orderly implementation of all test cases, and to record implementation info.
If the monitored behavior prototypes cannot be directly detected as failures, information requires to be recorded for analysis.
As soon as the implementation result is received analyses may be performed to compare the specific behavior and output with the expected ones. This comparison is needed to define whether it is expected behavior or if a failure happened is called the testing oracle problem.
In such a way black-box testing verifies if the observed behavior conforms to user anticipations or product specifications. Failures related to specific external functions can be observed, leading to follow-up activities where corresponding faults are identified and eliminated. The focus is on decreasing the possibilities of detecting functional troubles by target clients.
Information recorded at test implementation is used to recreate fault scenarios, to forecast defects, to find fault reasons and detect specific faults in software design and code, and to correct them.