Killing off the V-model

12th May 2015 Pete George no responses Uncategorized

Just of late, I seem to have heard a number of references to V-Model or V-Model concepts. This strikes me as odd. Given I’m working in development contexts that are employing adaptive, iterative-incremental approaches, it just seems strange to hear people talking about a predictive, sequential model. While it would be rare for Agile software engineers to talk about Waterfall ideas (except as an object of ridicule), for some reason, reference to V-model ideas are still quite socially acceptable. Musing about it a bit, I’m wondering whether it is not just odd, but that persisting with these ideas in an agile context is actually very damaging.

This is not a criticism of those adopting a Waterfall/V-Model approach (they have enough problems of their own), but rather it is an appeal to fellow software engineers, who are already in an agile context, to decisively put to death the insidious hangovers of V-model thinking.

As someone who has specialised in software testing for much of my career, I’m very aware that one of the main reasons for the prolonged existence of the V-model has been the unquestioning allegiance of a large section of the software testing community. This may have been justifiable in the 1980s when software testing pioneers were fighting against the flaws of the predictive, sequential Waterfall model, but these days, testers maintaining a V-Model mind-set run the risk of holding back the software development community.

The kind of thing I’m thinking about is referring to V-model concepts like ‘levels of testing’. The V-model breaks up the traditional Waterfall test execution phase into multiple levels of testing e.g. unit, integration, system, user acceptance test levels. Although it is obviously true that there are different levels of maturity for a product and hence it makes sense to consider different types of testing at those different levels, in an iterative model testing at different levels of maturity occurs contiguously throughout the iteration, not sequentially as in Waterfall/V-model. Unfortunately, my observation is that V-model level thinking too easily lapses into thinking in terms of sequential delivery, e.g. “when we’ve finished system testing we’ll run the UAT”, with all the problems that entails.

My suggestion is that references to a V-model concept, e.g. “we need to think about the left side of the V” et al., are a good indication that there is a flaw in the agile approach being adopted. So, a good practice could be that whenever we hear (or articulate) a V-model concept, to stop and reflect. Is that really what is meant? If so, why are we reverting to a predictive approach? If not, what is it we’re really trying to do, in order to deliver complex software in an adaptive and iterative context?