Do better testing ! The longer bugs remain in a program, the more costly it is to remove them.
This old adage has been supported by many studies, e.g. the U.S. National
Institute of Standards and Technology (NIST) study in 2002. Software bugs, the
study said, cost the U.S. economy about $59.5 billion a year. Further, over half
the bugs in software were found late in the development process or even after
the software was selling on the market. The cost could be cut by some $22 mil-
lion by better testing at early stages of development.
Testing can be fun. To paraphrase a former student of the younger author,
testing is a Good Thing because you approach it with a different mentality than
when writing code. When writing code, you are just trying to get it done; when
testing code, you are trying to “break it”, you are trying your best to make it work
An introduction to testing
We begin with a discussion of testing methods since the method is generally the
smallest testable unit of a program. Later, we make a few remarks about testing
First, we always try to follow this guideline:
Guideline: Test each method thoroughly as it is completed.
Of course, this may not always be feasible because several methods may inter-
act in such a way that testing them together is necessary.
But there is a good reason for this guideline. Once a method is tested and its
correctness is assured (as much as possible), you will be quite sure that any error
that arises is not in that method. It lies elsewhere. This reduces, to a large extent,
the areas of the program to be investigated when developing test cases, testing,
The tendency, once a method is written (but not tested), is to move on to the
next one. Following this tendency will assuredly end up costing you more time
in developing and testing the program. Resist the tendency.
A second guideline is the following:
Guideline : When both writing and testing a method, understand
exactly what the method is supposed to do —this means that the
method specification should be written before the method body.
Software quality teams . Because of the high cost of leaving bugs in a program, some compa-
nies have quality assurance (QA) teams that do nothing but test software. A
team is given the specification and software, and the software is not released
until this team okays it. Even then, software is sold with bugs. The best way to
ensure there are no bugs is not to put them there in the first place. That, of
course, is hard to do.