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 familiar. 1
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 like this:

Full article...

Other Resource

... to read more articles, visit http://sqa.fyicenter.com/art/