Agile Test Automation
I just posted an agile automation presentation on my site that expresses an agile approach to the classic problem of test automation. This approach can be used for test automation for any kind of project, whether or not that project is itself “agile.”
(Note: Agile test automation is a term sometimes used to mean whatever Extreme Programming afficiandos do to test– usually tiny little unit tests. Since most Extreme Programming people have so little background in testing and so little participation in the testing community, this may not be surprising. Still, that’s an overly limited idea of test automation.)
The gross summary of the method is this: instead of establishing a team of test automators who create a huge test automation framework that takes months to make work, identify at least one test toolsmith who pairs with testers and in less than 40 hours (preferably less than 16) identifies and implements some technology that helps make that tester more productive. Then repeat. Think of test automation as any tool supported testing, and think of test tools as any tool that may help (especially cheap or free tools). Avoid expensive tools, such as those from IBM/Rational or Mercury.
This is how I do test automation. I only just realized that it’s a definable approach. I’m working on an article about it with Cem Kaner. Bret Pettichord also does this kind of thing.
February 14th, 2008 at 9:17 pm
Hi James,
Me also following here this agile test automtion technique and we are highly
benefiting by getting the testers involved to know what they want and to
see things working in short time span,and basically keeping this pace ,parallely
we also have the massive automation developed,in small phases using agile test automation.After more than a year of automation,we had finally started to see success in keyword driven automation for the embedded automation which was once a night mare.I would like to join you in your research in this area if you do not mind.
- Kesavan
( You can reach to my works in testing, in google search )
November 4th, 2008 at 4:55 am
Hi James,
Many thanks for this article. I’ve been struggling with the transition to agile and the expectation that I am to automate tests, when I am not an automation engineer. I actually solved it by pairing up with an exceptional toolsmith who is taking basic Selenium recorded scripts (mainly recorded whilst I am doing my exploratory testing) and bundling the successful and ‘repeatable’ (for the expected regression) in with the development CI nightly build. The results are then put in to a DB and a dynamic web page is spun up so I can drill through all of the results. Metrics are produced off the top.
In essence this is what you are recommending and I thank you for putting some text around a theory I’ve been struggling to quantify. It works a treat and means I can spend much more time exploring the software and finding potential bugs.
Cheers
Rob