This post is one of a series examining the role of test in various software development processes. Today we'll look at the Extreme Programming (XP).
How I got here:
This is one of those processes I've only used on small projects. But boy did it happen wholeheartedly; there were user stories, task cards, daily standups, pair programming, red bar/green bar development, and automated acceptance tests. The results have been a success, but on a small scale - the project simply hasn't grown for business reasons.
The role of test:
Certain types of testing are central to XP. In particular, red bar/green bar development is very test centric. There is also a role for "automated acceptance testing". Test is understaood to be automated first and foremost. The emphasis on rapid iterations, near-continuous refactoring, and other short cycle development techniques places huge value on very rapid testing across the application, almost always in automated form. Where manual test is mentioned, it is strongly discouraged.
Test takes a very central role in XP. It's the foundation that makes other practices - especially continuous refactoring and short release cycles - work. This makes test the problem of very member of the team, and can help developers think like testers. Testers are able to expand coverage quickly and easily, keeping up with the samller features added.
The rejection of manual testing makes certain types of tests very difficult. In particular, automated GUI testing is a weak point because of the high maintenance costs this type of testing imposes. This process is also difficult to sell to a typical development organization for planning (or lack thereof) reasons. Test creation is also centered around the developer, and training a developer to test thoroughly may or may not be feasible; it's simply a different skillset.
In the end:
For non-test reasons, I think using XP as a process is difficult in a corporate environment - although I certainly encourage it as a great team learning process. I also think the emphasis on automated test is ill-suited to GUI testing. 100% automation isn't a goal I think is realistic.
DISCLAIMER: All thoughts on processes are my own and are meant as reflections of my experiences with them, not with the theory of the process itself. No flamewars, please.
Other Posts in this series:
Test in Process: A Series (http://blog.abakas.com/2007/08/test-in-process-series.html)
Test in Process: RUP (http://blog.abakas.com/2007/08/test-in-process-rup.html)
Test in Process: XP (http://blog.abakas.com/2007/08/test-in-process-xp.html)
Test in Process: SCRUM (http://blog.abakas.com/2007/08/test-in-process-scrum.html)