background image
<< Table of Contents | Different Models of Software Development >>

Introduction

<< Table of Contents | Different Models of Software Development >>
I n t r o d u c t i o n
The Need for Testing
My favourite quote on software, from Bruce Sterling's "The Hacker Crackdown" ­
The stuff we call "software" is not like anything that human society is used to thinking about.
Software is something like a machine, and something like mathematics, and something like language,
and something like thought, and art, and information.... but software is not in fact any of those other
things. The protean quality of software is one of the great sources of its fascination. It also makes
software very powerful, very subtle, very unpredictable, and very risky.
Some software is bad and buggy. Some is "robust," even "bulletproof." The best software is that
which has been tested by thousands of users under thousands of different conditions, over years. It
is then known as "stable." This does NOT mean that the software is now flawless, free of bugs. It
generally means that there are plenty of bugs in it, but the bugs are well-identified and fairly well
understood.
There is simply no way to assure that software is free of flaws. Though software is mathematical in
nature, it cannot by "proven" like a mathematical theorem; software is more like language, with
inherent ambiguities, with different definitions, different assumptions, different levels of meaning that
can conflict.
Software development involves ambiguity, assumptions and flawed human communication.
Each change made to a piece of software, each new piece of functionality, each attempt to fix a
defect, introduces the possibility of error. With each error, the risk that the software will not fulfil
its intended purpose increases.
Testing reduces that risk.
We can use QA processes to attempt to prevent defects from entering software but the only thing
we can do to reduce the number of errors already present is to test it. By following a cycle of
testing and rectification we can identify issues and resolve them.
Testing also helps us quantify the risk in an untried piece of software.
After modifications have been made, a piece of software can be run in a controlled environment
and its behaviour observed. This provides evidence which informs the decision to move to the
next phase of the project or to attempt to rectify the problem.
And finally in some (dare I say enlightened?) software development efforts, testing can actually be
used to drive development. By following statistical models of software development and methods
such as usability testing, software development can move from an unfocused artistic endeavour to
a structured discipline.
This primer will be unashamedly pro-testing. I am, and have been for ten years, a tester. As a tester I
have suffered endless indignities at the hands of project managers and development teams that
resulted in enormous amounts of stress for myself and my teams.
There are plenty of books written about and for project managers and software developers.
This is probably not one of them.
3