IBM 1130 User Manual page 213

INTRODUCTION
Now that programming is "finished", it is time to
evaluate what you have in relation to your objectives.
Do your programs and systems produce the results
you want? To find this out you must test the pro-
grams -- but not until you have a plan.
Experience has shown that more time can be
wasted in testing than has originally been allotted
to testing.
In other words, testing must be performed ef-
fectively.
* * * * *
There is a great temptation to get a newly writ-
ten program on a machine and see it run. A little
extra effort before going to the machine can save a
great deal of time and effort in the long run. If you
must travel some distance to test a program before
the installation of your own machine, it also means
real money saving.
The chances are very good (99.99%) that your
program contains errors of various types:
1. Programmer clerical errors.
It
is easy to
make minor clerical errors when filling out the
coding sheets. Although they are minor, the pro-
gram will not work properly until they are corrected.
2. Programmer procedural errors. The number
of procedural errors will depend on the experience
and proficiency of the programmer. These are
caused by not adhering to the programming rules as
outlined in the language manuals.
3. Card punch errors. Errors may be intro-
duced when the program is punched into cards.
Punching programs into cards is very exacting, and
the keypunch operator must be very careful. Be-
cause of the nature of the information on the pro-
gram sheets, it is difficult to achieve speed and
accuracy in punching.
4. Program logic errors. Logic errors may be
caused by poor or incomplete analysis of the problem
prior to programming, or by incorrect programming
after correct analysis. In any event the program
must be able to either process, or properly reject,
all the various pieces of information that will be
given. Someone who is intimately familiar with the
procedure, as it is now being done, should review
the logic of the program for completeness.
Section
Subsections Page
30 01
I
00
01
Most clerical errors, both programming and
card punching, can be detected by a careful review
of the material. Key verification should always be
done, and
it
is essential to proofread coding sheets
before they are punched. The most common errors
occur in the use of 0 and 0, 1 and I, 2 and Z.
Standards should be adopted in which, for instance,
alphabetic
°
is written 0, zero is
0,
Z as..g, I as a
printed capital (I), and 1 as a straight line
(I). It
is wise to formally familiarize your keypunch oper-
ators with the adopted conventions.
Program procedural errors can often be detected
by having someone other than the original pro-
grammer review the programming sheets. Even
where the programmers are relatively inexperienced,
they will often catch errors in syntax (grammar of
forming statements). This review can also serve as
an excellent way to improve programmer knowledge.
During a review of the program, program logic
errors are more difficult to catch. This is particu-
larly true when the person who is familiar with the
procedure is not also familiar with programming.
Logic errors are generally caught during testing
when sample data is processed by the program. The
sample data must be prepared so that all of the vari-
ous exceptions, combinations, and ranges of infor-
mation are introduced to the program, insofar as
it is practical to do so.
It
should be remembered
that any element or combination of elements that is
not tested is very likely to appear eventually; if it
can happen, it will.
At the time that your program is assembled or
compiled on the system you are installing, a series
of diagnostic tests is also made to detect many of
the potential errors, and these errors are noted.
By properly prechecking your programs, you can
materially reduce the amount of time to get a pro-
gram compiled and tested successfully. Care in
the preparation of test data will also detect logic
errors so that they can be corrected before the proc-
essing of actual data.
The final test of any program is the successful
processing of "live" data, after which the results
can be compared against those obtained by the pre-
vious system.
Note: If the results of this last test do not agree
with previous results, check again to be sure what
the right answers should be. Sometimes the old
system has not produced the correct solutions.