Back

Another example of selecting test data

Introduction
Data used to test programs is not selected randomly. Different categories of data are selected to test the common situations found in programs. Valid data is selected, to check a program works. Invalid but perfectly feasible invalid data is chosen, to check the program can cope with invalid data. Many errors occur where 'borders' happen around data (see below for an example of borderline data tests) so borderline tests are carried out as well. In addition, you will see tests dealing with extreme data of the correct data type, and data of a completely incorrect data type being tested.

Typically, tables are drawn up in a test plan. These use the following headings:

• • Data to be used.
  • Why the data has been used.
  • What the predicted outcome is.
  • What the actual results were when the test was carried out.
  • Any comments (comparing the predicted with the actual results).

You can see an example of this below.

An example of selecting data for white box testing
If you are testing the code as the programmer, you may have to test:

IF (Result > 9) DO
       XXXXXX
Else
      YYYYYY
End IF

The programmer will want to test the routes through the program. They might select the following data:

      5 (less than 9)
      8, 9 or 10 (borderline)
     15 (greater than 9)

An example of black box testing
When deciding what data to use during black box testing, the programmer might consider the following categories of input data:

• • Valid data.
  • Invalid data.
  • Extreme data.
  • Mad data.
  • Borderline data - bugs lurk in corners!

Suppose a subroutine has been written.

• • The program asks the user to enter in a test mark between 0 and 100 as an integer.
  • It outputs a grade.
  • A student must re-sit the test if they get less than 50.
  • A pass is from 50 to 70 inclusive.
  • A pass with honours is from 71 to 100 inclusive.

You are a program tester.

• • You have been given the subroutine by the programmer to test.
  • You do not have knowledge of the actual code (the programmer wrote it, not you).
  • You do, however, know what it is supposed to do because you have been given its Requirements Specification.
  • You might draw up a black box test plan and produce the test results as shown in the Test Plan on the next page. (Note this test plan is not exhaustive – there are other tests you could add to the plan!)

An example of a black box test plan and results.

When you completed the tests, you would pass the results back to the programmer. They would need to investigate why the test that used the data 49 failed - it did not produce the expected outcome. They would then re-submit it to you for re-testing.

Back