This post originated from an RSS feed registered with Agile Buzz
by Jared Richardson.
Original Post: Problems with Test Automation
Feed Title: Jared's Weblog
Feed URL: http://www.jaredrichardson.net/blog/index.rss
Feed Description: Jared's weblog.
The web site was created after the launch of the book "Ship It!" and discusses issues from Continuous Integration to web hosting providers.
When I spoke at Adobe last week the title of my talk was It's All About the Platform. The presentation was about how to effectively leverage test automation and continuous integration to validate your platform products. After the talk a former Microsoft employee asked me why I didn't talk more about the problems with test automation.
I think I addressed the concerns at the time, but it's a good question that bears repeating.
First, you can only cover so much in a sixty to ninety minute talk. I already had more material than I could do justice. Trying to present the case for test automation, then continuous integration, then presenting some counter-points... it was beyond the scope of the talk.
Secondly, I've never encountered a shop that wasn't top-heavy on manual testing. In my experience, there aren't many shops abusing automated testing. So I present on topics like this I try to push hard towards automation, not because I think it's all you need, but because I'm trying to restore balance.
If your shop has only manual or only automated tests, you lack balance. You need a good mix of both. In pushing people towards test automation, I'm trying to establish that balance, not wipe out manual testing.
That leads into another good point. Test automation can't replace a skilled interactive tester. It can eliminate a lot of boring, repetitive work. It can keep the basic product rock solid, freeing up the (presumably) smart, creative human to look for another class of problem. You need testers and test automation. Neither stand-alone.
It takes a different sort of mind to do interactive, manual, black box testing than it does to do programming or test automation. Some people take a shot at programming and they just Get It. Other people are the same way when it comes to intelligently probing a program's limits. When your company decides to initiate an automation effort, please don't blindly convert your interactive testers to test automaters. Just because both titles contain the word test doesn't mean they require the same skill set. Some people may overlap the two jobs, but many others will not. If you do a blank convert of an entire department, you'll likely condemn your effort to fail and frustrate some good people along the way.
Remember to provide some structure when you start creating automated tests. A little design and architecture has been known to greatly increase the value of software. ;)
On the other hand, turning a dozen people loose to write automated tests (for the first time in their life) might create some really bad tests. Be sure to adopt a strategy that can guide the team and make sure they are doing the best job they can do. Blitzkrieg Testing is a great starting point for providing that structure.
Test automation is an extremely powerful tool that I rarely see properly utilized. It's not a magic wand or silver bullet, but it's a tool that you can use in your shop everyday.
So, when's the last time you wrote an automated test? When's the last time you wrote one?
Previous Topic
