Test Management Featured Article

Sometimes I think we’ve gotten away from the first killer app of the computer: automation. Computers speed up communication and bring flexibility and better storage, but the original promise of computing values and automating work sometimes gets lost in all the communications buzz.

Software developers are less prone to this tendency to not automate, but still there is low-hanging automation fruit that goes unplucked—like testing automation.

Manual testing usually wins in a software development environment because it didn’t make as much sense to set up automated testing back when development was done with a waterfall methodology; it often was just easier to run the tests manually than to set up an automation routine for it. And during testing under a waterfall methodology, there also often is the need for “just get it done yesterday” speed, which isn’t exactly conducive to developing automated testing.

Agile (News - Alert) development changes the automated testing equation, however.

Instead of just running tests at the end of a software development cycle, with agile development it now is important to test at the end of each iteration.

“Every time we change code, there is a chance that change could break something that was already working,” added Chris Wright in a recent Zephyr blog post. “Instead of doing a few regression testing cycles in the maintenance phase of our projects or after some bug fixing sessions, regression testing is necessary after every single iteration—which could be as often as once a week.”

Automation makes a lot more sense in an agile environment, both from a time saving perspective and also an economic perspective.

Wright recommends some basic automated smoke tests to get started, but not to stop there.

“Eventually you’ll want to move on and build out a full automation framework,” he noted. “Many automation projects fail, because adequate effort is not put into architecting a full, robust solution for testing. Automation requires a significant and real architectural effort to support it. Using a simple record and playback automation tool might seem to give rapid results, but that approach is unmaintainable and will cost more money and effort in the long run when tests continually break from small changes in the application under test.”

A better way is to set up an automated testing framework that can abstract the application away from the automation tests themselves. But, of course, that takes time.

Setting up automation always takes a little investment. But as every software developer knows, a little investment in automation can save a lot of effort later—and prove better code later when each iteration is properly tested.