Information Technology Reference
In-Depth Information
10.14 Testing Alternatives
A great number of nuances are being discovered in relation to software testing.
These nuances combined with the complexity of software systems provide what is
a never ending bug removal cycle. Just as the complexity barrier indicates: chances
are testing and fixing problems may not necessarily improve the quality and
reliability of the software. Sometimes fixing a problem may introduce much more
severe problems into the system, sometimes after bug fixes, such as the telephone
outage in California and eastern seaboard in 1991. The disaster happened after
changing 3 lines of code in the signaling system (Pan
1999
).
Software testing as old as the first program still is a prime target of research and
industry specialists. These individuals realize that software bugs may be incom-
prehensible to us for many reasons. For many, it is the sheer amount of information
that is required to analyze all aspects of a system. For others, it is the obtuseness of
code or a model. Still, other times there is just not the correct algorithm for solving
the problem so it must be completed in a least then optimal method.
However, testing is by no means a waste of resources. It is just beneficial to
know the downsides and the tools available to promote better, faster and more
efficient testing. Many testing frameworks are in existence to provide testing for
anything from embedded systems, to web applications to POSIX implementations
in various kernels. The best software engineers know their own limits and where
they need to bring in outside assistance, whether in the form of a toolset or more
human capital.
10.15 When to Release the Software
After a product has been successfully maintained for many years, it eventually
may lose its usefulness and be superseded by a totally different product. A product
still may be useful, but the cost of porting it to new hardware or running it under a
new operating system may be more than the cost of constructing a new product,
and using the old one as a prototype. Testing is potentially endless. We cannot test
till all the defects are unearthed and removed.
When will the software ship (hopefully it will). Release time can be seen as a
function of resources divided by cost over time. In this scenario the software
testing will continue until the resources of money, equipment and human labor are
no longer financially viable. This scenario driven by profit provides what someone
has deemed as the most cost efficient testing available. The second scenario retains
the same function of cost, but is mainly time limited. The software must ship by a
certain deadline. This deadline be it arbitrary (someone likes the fifth of October
for no valid reason) or purposeful (to mesh with another product's release date) is
the sole factor of testing time. This method assumes that resources are bountiful,
implementation is complete and you test until you are cut off. It may be obvious to
