Information Technology Reference
In-Depth Information
and the connectivity design. Intuitively, this seems reasonable. If the system design
documentation is incorrect or incomplete, then no programmer can overcome a bad
design with good code. A dearth of requirements, the most fundamental develop-
ment documentation, is endemic to software development. The typical developer's
attitude is, “Just tell me what you want and I'll build it.”
To demonstrate the fallacy of bypassing requirements documentation, recall the
children's game called “Gossip” in which everyone stands around in a circle, and
the game leader whispers something to the person on his or her right. That person
then whispers the same thing to the person on his or her right, and so on around the
ring. When the whispered message makes it around the ring to the last person, the
person says the message aloud, and the leader compares it to the original message.
Usually, the whole circle of children burst out laughing because the original message
was twisted and turned as it went around the circle. Now replace the children in the
circle with a business manager who wants a new software system or another product,
a director of software development, a software development manager, and say four
senior software developers. The director starts the game by whispering his/her new
software application requirements to the nearest manager in the circle. Would you
bet your company's future on the outcome of the gossip circle? Many companies
still do.
1.5 TESTER VERSUS DEVELOPER ROLES IN SOFTWARE
TESTING
In the beginning, there was the software developer and he was mighty. He could
write specifi cations, could code programs, could test programs, and could deliver
perfect systems. Testers were nontechnical employees who volunteered to come into
the offi ce on a weekend and pound on a computer keyboard like a trained monkey
in exchange for pizza and beer. The emergence of a massive Y2K catastrophe
threat changed technical perceptions forever. The software developer's shiny
armor of invincibility was considerably tarnished, whereas the tester's technical
acumen rose and shone like the sun. It is now very clear that both the developer
and the tester have specifi c, complementary, highly technical roles to fulfi ll in the
development of good software. This section examines some of the issues around
these new roles.
1.5.1 A Brief History of Application Quality
Expectations, or “Paradise Lost”
The fi rst software development and operation environments were closed to the end-
user. These systems were predominantly batch processing, that is, end-users fed the
systems boxes and boxes of daily transactions on punch cards or paper tape and then
received the reports the next day or the next week. What happened in between the
submissions of batches and the production of reports was considered magic.
Search WWH ::




Custom Search