Overview of Testing - Software Testing: Testing Across the Entire Software Development Life Cycle - page 15

per defect, primarily due to the increased diffi culty in defect diagnosis and correction
for this larger aggregation of code that has been packaged for delivery.
Does it really save money to wait and test the software application or product just
before it goes out the door? Thirty years of industry statistics say a resounding “NO!”
The story gets worse. If the development manager decides to scrimp on testing
or skip testing completely to save a few thousand dollars and “let the customers help
test it,” the manager will experience the largest project defect correction cost. Capers
concludes that it costs on average $14,102 to correct each defect that got past the
development team entirely, and that is detected by the customer who receives the
application or product. Now the cost of defect correction must also include diagnosis
at a distance, package level correction, and the delivery of the correction fi xes to
all customers of the product, not only to the customer who found the defect. If the
customer has already installed the application or product and is using it in mission
critical situations, then the developer's challenge to fi x the customer's code is somewhat
like trying to fi x a fl at tire on a car… while the car is going 50 miles per hour.
1.3.4 The Pot of Gold at the End of the Internet Rainbow
Software that provides businesses with a presence on the Internet can represent
billions of dollars in new revenue to a company. This truly staggering business
sales increase is possible because the Internet immediately expands the businesses'
customer base from a local or regional base to a worldwide base. This phenomenal
business sales increase is further possible because the Internet immediately expands
the store hours from an 8-hour business day in a single time zone to 24 hours, 7 days
per week.
1.3.5 The Achilles Heel of e-Business
The lure of a staggering business sales increase causes business executives to drive a
company into its fi rst Internet ventures with a haste born of a king's ransom promise.
Everything done by the software development team is scrutinized to fi nd ways to cut
corners and save time-to-market , to cash in on the king's ransom before the competi-
tion does. One of the fi rst software development steps to succumb to the “gold rush”
is the proper documentation of requirements. The mandate is, “Just do something
… now !!!” Testing takes on the appearance of a speed bump as the executives race
toward going live on the Internet.
These business executives either forget or disregard the other side of the equation,
that is, the amount of risk in completing such a venture with a new, untried (from the
company's perspective) technology. If the company stands to gain billions by the successful
completion of the fi rst Internet venture, the company also stands to lose billions if the fi rst
Internet venture fails. And failed they did, in droves, during 2000 through 2002.
So, two lessons can be learned from what is known as the “dot.bomb” crash.
These lessons can be related surprisingly easily to other instances of companies
rushing into new technology markets. First, you can take too many shortcuts when