With a lengthy implementation period and a focus on long-term gains over static, unchanging tests, most people’s idea of test automation seems to be incompatible with the fluid, iterative Agile development methodology. Are these two really incompatible, or are we just not thinking about it the right way?
Photo courtesy of Wally Gobetz (Creative Commons)
| Regression testing falls directly into automation’s wheelhouse. Even in a fast-paced Agile environment, the up-front effort to automate regression testing will pay itself back almost immediately as sprint after sprint pass by—all without any delay from your testing team. |
If test automation is water, then the Agile development methodology is oil—at least that’s what most people tend to think.
If I’m being honest, that’s what I thought for a long time as well. The traditionally-accepted ROI of test automation tends to be realized through the long-term aggregation of savings over time (which, in the case of a large-scale business application or ERP system like Oracle EBS, tends to be pretty short). Unfortunately, those massive savings can come at a bit of a cost—requiring a lengthy script recording process, static, unchanging test cases, and copious documentation.
This seemingly puts the proverbial nail in the coffin, no? Automation is completely at odds with the ever-fluid, iterative Agile methodology, right?
Well, it’s not quite that simple. Just like the optical illusion pictured above, we just need to look for common clues and focus our perspective upon them. And in the case of automation and Agile, that means focusing on one of the only static things in all of Agile development: regression testing.
While it’s a well-known fact that an Agile build is always in a state of perpetual change, what’s sometimes forgotten is the fact that the same old regression tests are required for every sprint. Now, this wouldn’t be a problem for testers if these tests could be executed quickly or the developers weren’t trying to move onto the next sprint ASAP—but unfortunately, neither are. With the speed required of an Agile development, manual regression testing is often shortened—or worse, skipped altogether—delaying vital feedback to the developers and leaving a host of defects and/or bad fixes hidden inside their code.
Thankfully, regression testing falls directly into automation’s wheelhouse. Even in a fast-paced Agile environment, the up-front effort to automate regression testing will pay itself back almost immediately as sprint after sprint pass by—all without any delay from your testing team. This not only will prevent new bugs from being introduced in these areas; it will also free your testers up for more tests that can’t be automated, like usability and exploratory testing. With automation, you’re not just testing faster, you’re testing smarter too.
It’s worth mentioning that regression testing isn’t the only type of automation you can do in an Agile environment. Load testing is also huge here, as is the relatively new practice of automating each new functionality within the current sprint (though this is relatively advanced, and should only be attempted by mature teams that are proficient in Test-Driven Development)—but if you’re just starting to dip your toes into Agile automation, regression testing is the best place to start. It’s the lowest hanging fruit of the bunch.
See? A different perspective can work wonders—especially when you read between the lines.
Cheers,
Mike Hodge
Lighthouse Technologies, Inc
Software Testing | Quality Assurance Consulting | Oracle EBS Consulting
