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

complete the purchase. The web page that asked for his delivery address continually
responded with the nastygram, “City required, please provide your city name,” even
though he entered his city name in the appropriate fi eld several different ways, in-
cluding lowercase, uppercase, and abbreviated formats. In frustration, he abandoned
the incomplete purchase. Thinking that he would at least alert the toy store to their
Internet problem, Dr. Everett clicked the Help button. In the fi eld entitled, “Give us
your comments,” he described his roadblock to completing the purchase. When he
clicked the Submit button, a name and address page appeared. Upon completion of
the name and address page, he clicked the next Submit button, only to receive the
“City required, please provide your city name” nastygram again. The application
programmers earned an “A” for city fi eld code reuse and an “F” for not testing the
city fi eld code in the fi rst place.
An address is a pretty basic piece of customer-supplied business information.
The company had a software defect in the customer address code that resulted in the
direct loss of business. The defect was such that the company also could not easily
learn why they were losing business from their customers. It took this company less
than a year to close their Web site because it was unprofi table … perhaps all because
nobody tested a city fi eld code routine.
Testing principle 9: Assume the defects are the result of process and not
personality.
This principle presents an organizational behavior challenge for the tester. Good
software developers naturally feel a sense of ownership regarding the programming
they produce. Many aspects of the ownership can be positive and can motivate
developers to do their best possible work. At least one aspect of the ownership can
be negative, causing the developer to deny less-than-perfect results. The tester must
fi nd a way to focus on the software defect without seeking to place blame.
Many organizations have started tracking the source of software defects to
verify proper matching of programming task with programmer skills. If a mismatch
exists, the management process responsible for assigning development teams is truly
at fault, not the programmer who is working beyond his or her skill level. If the skills
are well matched to the tasks, the question becomes one of providing processes
that assist the developer in writing error-free code, that is, programming standards,
design walkthroughs, code walkthroughs, and logic-checking software tools. If the
execution phase is the fi rst time anyone else on the development team sees the code,
the development process provided no safety net for the developer before the code
has been executed. In this case, the tester can wear the white hat and, by identifying
defects, ultimately assist the improvement of the development process that helps the
developers write better code.
Testing principle 10: Testing for defects is an investment as well as a cost.
Most executives, di rectors, a nd ma nagers tend to view testing only as a n expense,
and to ask questions such as “How many people? How many weeks delay? How much
equipment? and How many tools?” Although these cost factors represent a legitimate
part of the overall business picture, so do the tangible benefi ts that can offset the
testing costs, business risk reduction notwithstanding. Some of the benefi ts can be