IBM 1130 User Manual page 214

Section
Subsections
Page
30 10
I
00
01
TESTING STRATEGY
Any good system is like a successful athletic team.
Each member must do his job well, and all members
must work together. These two things are what
you must accomplish with your testing strategy.
Each individual program is tested. When all pro-
grams give correct results, pairs are tested. When
the first pair gives correct results, another run is
added to the system. Finally, all runs are tested
together, and the entire system is checked out.
The individual tests are the foundation of the
system's test. A deck of test cards should be made
up for each program (or subprogram) and kept for
use in testing the program again in the future.
The ideal rule to follow in deciding what test data
to include is this: include every field at least once
under every condition in which it can occur, not
only by itself, but with every possible combination
of conditions in which all the other fields can occur.
With a simple program this is easy enough to do,
but where many fields appear under many conditions,
the number of possible combinations can become
enormous. Then your programmer must use his
judgment in making up a limited set of test cards
that covers the possibilities adaquately.
The test cards should be created, then listed.
For each set of test data, a "prediction" of the re-
sults that will appear on the output forms or cards
should be made. Then, when actual testing is per-
formed, your programmer cannot be easily misled
into believing that his output is correct when it is
not.
The first data in the test deck should test only the
ordinary, easiest, most straightforward conditions.
Next, multiple conditions can be combined on one
card or record. Finally, error conditions can be
tried. The reason for this careful progression is
that unless the simple situations are proved first, it
is possible to spend many hours trying to determine
which of several possible causes for a "bug" is the
true one.
Avoid setting up your tests in such a way that you
count on the output of one program to act as input to
another. Have at least one independent set of test
data for each program you are testing. "Merged"
or "linked" testing is a valuable means of proving a
system's overall validity, but it should not be done
until each program is individually tested.
After a successful test, both the test input and
output should be retained, as part of program docu-
mentation, to make future testing easier. Also,
when testing program modifications, test not only the
modifications but the entire program. In other words,
your sample test data should expand with each modi-
fication, so that the entire system may be tested at
any time.