Agile Test Automation: Breaking Through the Regression Bottleneck

If there’s one fundamental challenge about testing in Agile, it’s keeping up with the speed of developers.  But while you don’t want bottlenecks, you don’t want to sacrifice quality, either.  So, how do you make sure your testers don’t fall behind?  Automate as much as you can—then automate a little more.

No matter the task, a team is only as strong as its weakest link.

Whether it’s that friend who never showed up to help you move or the short guy on your pick-up basketball team who’s always getting dunked on, collaborative efforts will only ever be as good as these limiting factors allow.  It doesn’t matter how good everyone else is, it only takes one person to hold everyone back.

Unfortunately, when it comes to Agile software development projects, that weak link is almost always your software testing team.

Here’s the crazy thing, though: it’s not really their fault.  The truth is that—in an Agile environment—your testing team is pretty much doomed from the start.  Since Agile thrives on fast, iterative development sprints, your testers will eventually reach a point where they’ll be unable to keep up.

It’s simple arithmetic, really.  While the first few sprints may not cause any problems, as complexity grows so too will your testers’ responsibilities.  Eventually they won’t just be testing the latest batch of code; they’ll also be working to make sure that those shiny new functionalities aren’t disrupting any current features.

As developers and the business constantly push for faster sprints, QA organizations will often find themselves between a rock and a hard place: confront the metastasizing backlog of Regression Testing (drawing the ire of the speed-focused developers and business) or cut the backlog down to a more manageable load (which sometimes means cutting Regression Testing completely).  And while the former option is far more risk-averse, yielding a higher-quality finished product that doesn’t frustrate users or necessitate costly rework, it’s also significantly more expensive up front—which is why a fair share of companies opt to roll the dice with the latter instead.

It’s not rocket science; it’s simple utility.  Even though the tests could reveal potentially-catastrophic defects (leading to crippling delays and busted budgets), they’re too big a pill for the business to swallow.

Fortunately for all parties, the solution doesn’t require much imagination.  After all, if you’re looking to increase your testing speed, there’s no better way than test automation.

Though the up-front investment might give some folks in upper management heartburn, there’s really no faster way to an ROI than by automating Regression Testing.  It’s a seemingly-familiar refrain to Waterfall developments, but here the effect is multiplied: once you’ve done the initial legwork to automate your end-to-end script, you can reuse it for each subsequent script!  That means that your testers can attend to the new code while the regression handles itself.  Pretty nifty, huh?

Test automation can sometimes get a bad name because people don’t fully understand how they can swing an ROI after paying the obligatory tool-licensing fees and investing in personnel to develop the scripts.  That’s completely understandable, which is why we’ve generated an ROI calculator to help show the true power of completely-reusable, fully-automated test scripts.  And while it’s tailored a bit more towards a more traditional, Waterfall environment, it’s still a great first step for anyone to take nonetheless.

The bottom line is that, for as much trouble as Regression Testing can cause an Agile project, it really doesn’t need to be that way.  Drop us a line and see how our Agile automation experts can help strengthen your team’s weakest link.  As every coach knows, without a ceiling for greatness, the sky’s the limit.

Cheers,

Mike Hodge
Lighthouse Technologies, Inc.
Software Testing | Quality Assurance Consulting | Oracle EBS Consulting