Black box testing treats the system as one that cannot be seen in detail. The structure of the program is not taken into account. The tests are performed based on what the program does. This is sometimes called Functional Testing.
The functional requirements have been agreed with the customer. Thus they can see that the program performs as it was requested at the specification stage. It is difficult to know just how much of the program coding has been tested in this case, but it is the kind of testing which is very popular with the customer. The approach to testing should generally be as shown in the following algorithm:
– Code and unit test a component.
– Add the component to the existing combination.
– Test and debug the new combination.
Until all the components have been added.
Deliver the system for acceptance tests.
Unit testing or module testing uses white box techniques, which we’ll discuss shortly. It takes detailed structural information into account. Testing and debugging the new combination involves black box testing as you are testing to see that the components perform the desired task.
The acceptance testing stage takes place nearer the end of the software development and it follows an agreed test plan. It applies a black box approach to see how software conforms to the customer’s functional requirements. The technique of testing each module as it is developed does have problems. It is not possible to test the modules in isolation. This problem can be overcome by writing small sections of code are written to pass data between modules.
A Main Program segment which passes data to the module is called a Driver. The driver can also print results which the module passes to it. A Dummy Subprogram which is called by the module under test is called a Test-Stub. The test-stub may accept or pass data to the test module and confirm that it has been called properly occurred by writing a simple message to the screen, such as the name of the module under testing.
Therefore, black box testing involves the programmer looking at the outputs and inputs to a module. The details of the system are treated as if they are in a black box and can therefore not be seen. The programmer (tester) does not look at the code that is going to be tested.