A Software Testing Primer
By: Nick Jenkins
The Need for Testing
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.
Different Models of Software Development
The Waterfall Model
Making something can be thought of as a linear sequence of events. You start at A, you do B and
then go to C and eventually end up at Z. This is extremely simplistic but it does allow you to
visualise the series of events in the simplest way and it emphasises the importance of delivery with
steps being taken towards a conclusion.
Below is the “Waterfall Model” which shows typical development tasks flowing into each other.
Early in the history of software development it was adapted from engineering models to be a
blueprint for software development.
The five steps outlined are :
• Analyse the requirements of the project and decide what it is supposed to do
• Design a solution to meet these requirements
• Implement the design into a working product
• Verify the finished product against the design (and requirements)
• Maintain the project as necessary
The Waterfall Model was widely adopted in the early days of software development and a lot of
blame has been laid at its door.
Critics argue that many problems in software development stem from this model. Early
development projects that followed this model ran over budget and over schedule and the blame
was attributed to the linear, step-wise nature of the model.
It is very rare that requirements analysis can be entirely completed before design and design
before development and so on. It is far more likely that each phase will have interaction with each
of the other phases.
In a small project this is not a problem since the span from “analyse” to “implement” may be a
period of weeks or even days. For a large scale project which span months or even years the gap
becomes significant. The more time that passes between analysis and implementation, the more a
gap exists between the delivered project and the requirements of end-users.
Think about a finance system which is ‘analysed’ one year, designed the next year and developed
and implemented the following year. That’s three years between the point at which the
requirements are captured and the system actually reaches its end users. In three years its likely
that the business, if not the whole industry, will have moved considerably and the requirements will
no longer be valid. The developers will be developing the wrong system! Software of this scale is
not uncommon either.
A definition of requirements may be accurate at the time of capture but decays with frightening
speed. In the modern business world, the chance of your requirements analysis being valid a couple
of months after it has been conducted is very slim indeed.
Other versions of the waterfall model have been developed to alleviate this. One, the Iterative
Waterfall Model, includes a loop as shown below.
This model attempts to overcome the limitations of the original model by adding an “iterative”
loop to the end of the cycle. That is, in order to keep up with changing requirements the “analysis”
phase is revisited at the end of the cycle and the process starts over again.
This alleviates the situation somewhat but still introduces a considerable lag between analysis and
implementation. The waterfall model implies you have to complete all the steps before you start
the process again. If requirements change during the life of the project the waterfall model requires
the completion of a full cycle before they can be revisited.
Other Models of Software Development
In response to the waterfall model any number of new models have been developed and touted as
alternatives. Some are interesting and many have promise but all have their pitfalls and none have
delivered the quantum improvements they have promised
Iterative or Rapid Development
In iterative development, the same waterfall
process is used to deliver smaller chunks of
functionality in a step-by-step manner. This
reduces the management and overheads in
delivering software and reduces the risk
inherent in the project.
One of the major reasons cited for
software project failure (and a common
sources of defects) is poor quality
requirements. That is a failure to correctly
specify what to build. By delivering small chunks and validating them, the project can self correct
and hopefully converge on the desired outcome. This contrasts with the long lag times in the
A variation on this theme is “Rapid Applications Development” or RAD.
The phases are similar to waterfall but the 'chunks' are smaller. The emphasis in this model is on
fast iterations through the cycle. Prototypes are designed, developed and evaluated with users,
involving them in the process and correcting the design. The model is particularly suited to
projects in rapidly changing environments where the team needs to adapt to different situations.
Note that not all iterations need be complete, fully functional software. Nor should they
necessarily focus on the same areas of functionality. It is better to deliver separate 'increments' of
functionality and assemble the whole project only at the conclusion of the production phase. This
way you can take partial steps towards your completed goal. Each unit can be individually
developed, tested and then bolted together to form the overall product or system.
The diagram above indicates progress through the development life-cycle in an iterative /
incremental development. Early on the iterations focus on 'design tasks' and the emphasis is on
making design decisions and prototypes. As the project progresses tasks shift to development
where the bulk of the coding is done. Finally, the emphasis is on testing or evaluation to ensure
that what has been developed meets requirements and is solid, stable and bug free (ha!).
... to read more articles, visit http://sqa.fyicenter.com/art/