Wednesday 9 May 2012

Test execution in Agile - PDD to TDD

Yesterday there was a wide-ranging discussion about the absolute need to get automated testing up and running to underpin Agile development practices within the company I am currently consulting within.  My stance is a simple one; without a well tuned level of automation, the amount of time taken to execute and maintain a test execution set that gives coverage of the developed code and assures regression will soon start to outweigh the time taken to develop the features.  Sadly, the company has "had a go" in the past but never really got it up and running.

The Agile concept with regards to testing and automation is straightforward.  In phase zero set up your tools; get Fitnesse, Ruby, Watir, Bamboo, Buildmaster, Jenkins (formerly Hudson), Maven or whatever you choose sorted so you have your baseline builds and a test platform - why not even script a smoke test or base sanity test that can be automated and scheduled overnight for starters.  Get the "screens green" early, so people start to look at them.

Now for every sprint; after sprint planning the developers or QA/Testers get to the priority stories first and script a set of unit tests that encompass the acceptance criteria on the back of each of the story cards.  Get them within an executable test harness so they can be executed really easily. Run the job, and bits of the "screens" go red - great; now its the developers job to get the screens to green again by delivering those stories and writing just enough code to get he unit tests to pass (they don't call it Test Driven Development for nothing). Deliver coded functions, run (and pass) all scripted tests, commit code to baseline, get new baseline code, rinse and repeat.

At the end of each sprint all these created tests can be added to the scheduled test execution run that (assuming there has been an integration of the codebase) going forwards can execute every night, or just on a regular basis to give a regression result.  Effectively, the regression pack starts at basically nothing and then builds with every sprint, hand in hand with the functionality.  If you are really organised you can build the regression set quicker (as soon as tests are created) but you just have to be careful that all stories that are in play (with tests written) are "done" in the source repository before regression is run otherwise you will get failing scripts.

Of course this just deals with the unit tests, meanwhile the proper "Testers" are writing functional tests that could potentially be automated as well, but thats another story.

As for PDD - well that's Panic Driven Development, not uncommon in organisations that have had a false start at Agile, failed to get it going and been left with a lot of pieces and problems. Better avoided than implemented !

No comments:

Post a Comment