Waterfall development has a drawback – it can be so functionally driven that testing of more abstract concepts such as “is the user interface any good?”, “can I migrate from version X to version Y” and “does my software handle failures?” can suffer. Why is this?

The core reason is that these concepts often span so many functional items, that they cannot be easily contained within testing of a single functional item. They tend to slot into the system verification test cycle – yet in the waterfall method this is at the end of the development cycle and probably subject to the tightest time constraints, when it is probably too late to fix any major architectural problems.

How can agile help here? I would like to see specific stories – and even specific sprints – designed entirely around these more nebulous concepts. This necessitates a “hold the front page” attitude: a willingness to stop development of new functionality, and instead focus on consumability/failover/documentation based on testers’ experience of earlier stories. Perhaps this is a way to implement SVT in agile…

In discussion with a friend it hit me that one of the biggest obstacles in going Agile is trying to convince people to deliver “little and often”.

What this means is that you deliver just enough code to get the feature working and leave out any “I’m gonna put this here for later use” code. You also accept that this may lead to re-writes of that code in later iterations. This implies that your code is not designed to be extensible from the outset.

On the opposite side is that of having a long delivery time for your feature. This gives you the flexibility of spending a considerable time up front designing the infrastructure to support any code that will follow in that release. Unfortunately with this approach you get the inherent problems of having a long waterfall release; little customer interaction and often it’s too late.

Now, what does this mean for Test? Well, going back to the first statement in this post. I think in the transition to Agile it can be really tough to break a developers’ mentality to write extensible code. Thus from a Test perspective you get elements of both extensible and time-to-market, meaning…

Too much to test in too little time.