New Models for Test Development
By: Brian Marick
A software testing model summarizes how you should think about test development. It
tells you how to plan the testing effort, what purpose tests serve, when they’re created,
and what sources of information you use to create them. A good model guides your
thinking; a bad one warps it.
I claim that most software testing models are bad ones.
They’re bad because they’re mere embellishments on software development models.
People think hard and argue at length about how to do software development. They
invent a model. Then they add testing as an afterthought.
A testing model has to be driven by development – after all, we’re testing their work. But
when the testing model is an afterthought, it’s driven in the wrong way. It connects to
development activities in the places that are easiest to describe, not those that give testing
the most leverage. It builds upon what developers ought to do, not upon what they always
do even when they’re not following the rules. It lumps together activities that have no
essential connection and separates others that belong together. It suffers from all the
flaws of hasty thinking.
The result is ineffective and (especially) inefficient testing. Ineffective testing misses
bugs. Inefficient testing wastes money.
In this paper, I’ll do two things. First, I’ll attempt to demolish a bad model, the quite
popular “V model”. In the process, I hope to banish the phrases “unit testing” and
“integration testing” from our vocabularies. Second, I’ll describe a model I think is better.
But my primary purpose is not to claim I have the right model – it’s too early for that –
but to describe important requirements for test models that will replace mine. Those
requirements are summarized at the end of the paper.
What’s wrong with the V model?
I will use the V model as my example of a bad model. I use it because it’s the most
A typical version of the V model begins by describing software development as
following the stages shown here:
That’s the age-old waterfall model. As a development model, it has a lot of problems.
Those don’t concern us here – although it is indicative of the state of testing models that a
development model so widely disparaged is the basis for our most common testing
model. My criticisms also apply to testing models that are embellishments on better
development models, such as the spiral model [Boehm88].
Testing activities are added to the model as follows:
Unit testing checks whether code meets the detailed design. Integration testing checks
whether previously tested components fit together. System testing checks if the fully
integrated product meets the specification. And acceptance testing checks whether the
product meets the final user requirements.
To be fair, users of the V model will often separate test design from test implementation.
The test design is done when the appropriate development document is ready. That looks
... to read more articles, visit http://sqa.fyicenter.com/art/