Three Times When Automation Will NOT Make Your Agile Project Go Faster

We all want to use test automation to make our projects go faster. But it doesn't always work out that way. 

Here are three times when test automation can actually SLOW YOU DOWN:

When you don't treat test automation as "proper" software development

When teams consider test automation as simply "writing scripts", without proper design or without making the tests easy to maintain and scale over time, they inevitably get into trouble. For anything but the simplest of applications, the test scripts inevitably become larger and more complex. 

And when this happens, if you haven't build maintainability into your tests and testability into your system from the start, the tests become harder and harder to run and maintain, and take more and more effort to write, until the whole thing becomes unsustainable. 

When you automate in silos

It used to be a common practice to get a separate, often offshore, team to take care of test automation. But for an agile team, treating test automation as a siloed practice, even handing it off to another team or service, is one of the worst things you can do. The project team gets very little value from this sort of automation (it gets done too late to be useful for them, and any defects found will be slow and costly to fix).

When you focus on automating your manual test cases

It feels intuitive to first write manual test cases, and then automate them. After all, for a lot of us, that's were test automation started. You wait until a feature is stable and you have written test cases and done your manual testing, and THEN you start to automate.

But this doesn't really work for agile. It happens too late in the game. It's only really useful for regression testing, and doesn't help the team go any faster.

There's also a more subtle issue with automating manual test cases. The automated test cases are derived from manual test cases, which are derived from the original requirements or (just as often) from the tester's understanding of the application features. 

In all of these cases, test automation like this can easily become more of a burden than a benefit, at least from the perspective of the development team. 

But there is a better way! Many teams do get test automation right, and use it very successfully in agile projects. The ones that I see succeed combine three factors:

• They focus on automating REQUIREMENTS, not test cases, and they do this at all levels of the application;
• They take an ENGINEERING APPROACH to test automation, taking the time to design their test framework and building testability into their application;
• They put COLLABORATION at the heart of their test automation efforts; they start early, well before the sprint, and engage the whole team, not just the testers.

I've written more about this kind of approach in a short (9 page) ebook, that you can grab here:

?? Flipped Testing: How To Build Test Automation Frameworks For Agile Projects From Scratch Fast

Check it out, I'd love to hear how this approach compares to your own experiences!