I’ve just returned from a two day ‘Disciplined Agile Development Workshop’. Inspiring stuff! It HAS to be the way to go. Short iterations delivering real stakeholder value. Test driven development, continual integration – all that good stuff. But I must admit I have been wrestling with what that means for system test (SVT). My initial reaction was, well that’s easy, everyone else in the development team moves to the agile model and then SVT use the last iteration, when the code has stabilized and all the dependencies have been sorted out, to execute their scenarios, giving the testers several iterations of wonderful ‘prep’ time – much as we did in the waterfall model.

Fortunately I have seen the light!

I was falling into the usual trap – everyone else needs to change except me. The coders need to chop up their monolithic deliverables into smaller packages of value, but SVT could do ‘test prep’ throughout development until it all come together at the end. Wrong.

I have reset my mind now. Just in time.

Just as we expect the code to be delivered in small chunks of stakeholder value, SVT should be creating test scenarios that address these. With the intent that, after any iteration the product can be shipped knowing it has had the right level of testing. This will need a mindset change from the testers. firstly, they will need to be engaged through out the project, ready to verify new ‘bits of value’ each time they are delivered. They will need to adapt to the little and often approach that we are asking the agile developer to take. Secondly, they will need to find innovative ways of stitching these smaller scenarios together as the product progresses.

Take as an example the agile development of a new database (I’m sure we need another one). The iterations may deliver the use cases of being able to add and update data in the database in iteration one, and then read it in iteration two. The tester will need to generate realistic scenarios in iteration one without having the ability to read the records in the database. This will entail creating extra test code to ‘mock up’ the read. Now this may seem wasteful to the tester since that mocked up code can be thrown away after iteration 2. Well, its true that the code will be thrown away, but not true that it is wasteful because, looking at the project as a whole, considerable value will be added if the problems with ‘add and update’ can be thrashed out early in the cycle.

The test scenarios in iteration two will verify the new stories based around the read functionality as well as exploit the value of the add, update and read in a combined scenario.

I’ve never been a fan of the ‘test prep’ phase. why prep for test? Just get on with it. The day you first look at the product (be it the design, the documentation or the code itself) is the day you start testing. Drop the concept of test prep – lets just call it testing!

Tags: agile, svt, system

This entry was posted on Friday, February 1st, 2008 at 11:54 by Jon Tilt. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.