Fitting agile acceptance testing into the development process
It seems a comon problem. One of the first steps in implementing an agile process (such as scrum) is to put in place a fixed iteration cycle in development, but but then find difficulties fitting post-development testing (a.k.a “system testing” or “integration”) into the mix.
The main problem with testing after development is that any fixes to problems identified in the follow-on testing have a tendency to become tangled in upcoming work for the next iteration. This in turn can lead to no iteration ever being “clean” enough to actually release.
One possibility for a solution is to reconsider the development-led nature of an iteration, and instead lead it from a set of acceptance tests which are estimated, developed and executed alongside the scheduling and implementation of code changes.
Gojko Adzic, one of my current favourite bloggers on the subject of testing, has attempted to map out an iteration structure which incorporates this approach:
Gojko Adzic » Fitting agile acceptance testing into the development process






For years Frank Carver has been paying attention to the strange world of convergent technology. During that time he has discussed and researched broad subject areas, come to some surprising conclusions, produced and distributed digital media, scattered ideas and opinions like sparks from a firework, and above all consulted for businesses both large and small to help develop and deploy successful systems, services, and products in this highly complex arena.


The Punch Barrel / Automated story-based acceptance tests lead to unmaintainable systems | September 30th, 2008 at 10:29 #
[...] A fascinating counterpoint to Gojko Adzic’s writings on acceptance testing in an agile process. [...]