Testing Theory

Testing Theory

Testing is the process of running a program with the intention of finding errors.

Testing should be carried out systematically. It should never be done by intuition.

Most testing is top down, module by module testing.

There are two main approaches to testing:

1. Black Box Testing

2. White Box Testing

Black Box Testing

This 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:

1. Repeat

2. Code and unit test a component.

3. Add the component to the existing combination.

4. Test and debug the new combination.

5. Until all the components have been added.

6. 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 Stub. The stub may accept or pass data to the test module and confirm that the transaction has occurred by simply writing a message to the screen.

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.

Click on this link for further information on black box testing: http://en.wikipedia.org/wiki/Black_box_testing

White Box Testing

This treats the system as one in which the workings can be seen. The structure of the program is taken into account when tests are designed for the program. This is sometimes called Structural Testing. It should do the following:

1. Guarantee that all statements in the program have been tested at least once, ie: identify all pathways through code (eg: sequence, selection and iteration).

2. Test all the decision statements on their true and false side and check to see which of these paths have not been tested in the Black Box approach.

3. Test all loops at their boundaries and their operational limits.

4. Exercise internal data structures to check their validity.

5. Create new test data for paths not already tested.

Therefore, White Box Testing involves the programmer looking at every path through the coding. The details of the system are treated like a white box or a glass box through which the code can be seen clearly.

Click on this link for further information on white box testing: http://en.wikipedia.org/wiki/White_box_testing

Click on this link to read about white/glass box testing: http://www.cse.fau.edu/~maria/COURSES/CEN4010-SE/C13/glass.htm

Testing Terminology

The purpose of testing is to attempt to detect to logic errors in the code. The code should be tested using as many different types of data input as possible. It is estimated that the testing phase can take 50% of the time allocated for project development. Therefore, testing should be planned and thorough.
Integration Testing

Integration testing is testing the whole program when all of the modules are put together.
Test Case

A test case is a set of data which is prepared in order to test that the program produces the predicted result.
Test Plan

A test plan is a list of test cases which cover all circumstances which can arise. Each test case should detail the expected results.

The actual results of a test run are compared with the expected results for that test case to determine whether the test has been successful.