Original URL: http://www.theregister.co.uk/2007/03/12/xp_testing_method/

eXtreme methods

Different views...

By David Norfolk

Posted in Developer, 12th March 2007 10:14 GMT

Kevlin Henney raised an interesting point (here) about the view of eXtreme Programming in the revision to Myers' Art of Software Testing.

I didn't pick up on this in my review, probably because it never occurs to me to adopt normative development processes without also applying common sense – methodology (and why not call it method) should be a guide, not a master. Departing from the standard method will have consequences; if all of these are adequately addressed and the overall results are "better" (which implies that this only really works in a mature organisation with metrics behind "better"), then the departure is going to be OK.

Besides, as far as I know, there is no definitive statement of what XP actually is (and can't be, as an XP precept is "if XP is broke you're allowed to fix it" AIUI).

Anyway, I simply can't see anyone completing an entire system test pack before they do any coding any more than I see them producing an entire corporate data model before building anything. The principle of requirements being testable and of producing some tests before you start coding is still valuable, however; as is the principle of modelling data structures and relationships before trying to write code.

When I talked to Kevlin about this, he mentioned that the people who revised Myers seem almost to be recommending a sort of "reverse waterfall". Well, I can defend Waterfall too. As I understand it, the waterfall is actually an iterative process and no one, in practice, ever sets the requirements in stone and delivers on them five years later without a change. Mainly because so doing would make no sense (and isn't what Royce asked for anyway).

Kevlin's comment on this makes interesting reading:

Well, that's not a defence of the Waterfall: it's a defence of what Royce said, which is subtly different. In his original paper, Royce outlined a number of process models. Two things are notable about this paper: (1) he never used the term "waterfall" and (2) the process model that has since been named the Waterfall is one he criticises. However, he still gets the infamy associated with the process!

There are a surprising number of projects and companies that are drawn to the Waterfall as the default process. Closer inspection reveals why there is this attraction -- I wrote about it in Objective View 10 [big pdf download necessary - Ed].

In the end, of course, talking about "methodologies" is going to go on for ever. I sometimes think that actually following any method, as long as you're prepared to depart from it in a controlled way when this makes sense, is better than the common practice of not following any particular method - while paying lip service to something or other fashionable. ®