Fool Me Once: Follow-Up

[article]

Test Tool to Automation Application
What we learned from this history is that code is the culprit—the more you develop, the more time it takes, the more it costs, and the longer to maintain. And if you actually code every single test, you will end up with more code than the application has. Unless you have more time and people for testing than you do for development—and if you do, call the Guinness Book of World Records—then this approach is doomed.

It turns out that what you really need is not a tool but an application. The difference is code versus data. Using a tool results in code; using an application results in data. Why does this matter? Well, for one thing, you don't have to be a programmer to use an application, and that means your subject matter experts can participate. Second, data is easier to manage than code and can be maintained en masse, often automatically. And third, you may be able to buy an application rather than build one. For more on this distinction, see the WorkSoft blog.

There are many different ways to migrate from a tool to an application. For those who already have invested in a scripting tool, consider developing a framework that limits the amount of code that has to be developed and enables non-programmers to build tests as data. For those of you who haven't committed yet or who have shelved one or more tools, consider buying a commercial framework or adopting an open source approach. My favorite is the class/action architecture, also sometimes called table-driven, because it results in the least code and the code it does need is portable across tools and applications.

Setting Expectations
But the most important of all elements is to set realistic expectations about what it is going to take in terms of cost, time, and resources to implement and maintain automated tests. Automation is a discipline apart from manual testing and introduces new dynamics. Not only does the application have to be developed properly, but the test data environment has to be stable and repeatable—in itself a significant challenge—and test cases have to be explicitly documented and reusable.

And, although you won't ever automate everything—manual testing will always be needed for ad hoc, "what if" scenarios—and you won't be finished after the first project, automation is not only worth it but also inevitable. There is simply no other way to keep pace with snap-together, composite applications that allow rich, complex functionality to be developed in less and less time with more and more risk.

That's what I think works. What about you?

About the author

Linda Hayes's picture Linda Hayes

Linda G. Hayes is a founder of Worksoft, Inc., developer of next-generation test automation solutions. Linda is a frequent industry speaker and award-winning author on software quality. She has been named as one of Fortune magazine's People to Watch and one of the Top 40 Under 40 by Dallas Business Journal. She is a regular columnist and contributor to StickyMinds.com and Better Software magazine, as well as a columnist for Computerworld and Datamation, author of the Automated Testing Handbook and co-editor Dare To Be Excellent with Alka Jarvis on best practices in the software industry. You can contact Linda at lhayes@worksoft.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

May 04
May 04
May 04
Jun 01