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 an earlier blog I mentioned that there is a distinction between “load” and “stress” testing which is worth further clarification. This is important – as knowing which regime you’re in helps you understand a test’s value.

Crudely, load and stress testing involve pushing software/hardware at different levels, the latter “harder” than the former. Jon Tilt suggested a good analogy based around testing a passenger car. In a good demonstration of “reuse”, I’ve shamelessly stolen the analogy here…

(more…)

Recently my car has been unhappy – and not meeting the “service level agreement” I expect from it. I realised I was a software tester when I began defining test cases to determine what was wrong with it… which at least highlighted several parallels (and lessons!) between the “traditional” and software engineering disciplines.

(more…)