Automation Plan – Keep it simple

This content is syndicated from Agile Testing | Tester Troubles by Ray Claridge. To view the original post in full, click here.

automation
From my previous posts, you might think I'm anti in favour of automating tests. This couldn't be further away from the truth. In fact, providing it's well thought out, easy to maintain and gives you value for money, you'd be hard pressed to find a bigger automation fan than me.

However, I do have a problem when automation is mentioned, and everyone starts to get starry eyed thinking all their software problems are over. The reality is, it's not!

Ok - now my mini rant is off my chest,

here's my guide to making automation a success.



Business buy in - Before starting to automate, make sure you've got buy in from line managers and developers. Remember, automating is time consuming and will cost your company money to get off the ground.

Plan - Don't just start automating random functionality, have a plan and document explaining the approach and how long each test will take to develop. Remember, get sign off from all parties involved.

Identify high risk areas - Automating a fully fledged system is going to take a long time. So do some analysis to identify the high risk areas such as: most used, high volume, security or transactional sections and focus on them first.

Identify areas less likely to change - Maintaining automation test scripts is not a five minute job, so don't start on areas that are likely to change. Equally, don't assume that functionality less likely to change doesn't need testing. Past experience has taught me never to assume.

Document your tests - You need to this so that it's clear to others what exactly the tests cover. Also handy if your automated product is not available or your tests are falling over.

Keep track of your test runs - Keeping a chart of all you your tests and tracking automated vs manual effort, gives visibility that you're saving your company money. Also handy when trying to get buy in.

Keep it simple - Remember, tests should be simple so they can be re-used again and again. This keeps down the costs when maintaining and allows others to pick them up in the future, especially if you've got a contractor in to write the tests.

And lastly one for all the Product Mangers, Development Managers and Business Units -
Don't assume that because you've got someone writing automated tests that all your code quality issues are over. Remember - automation is only as good as the tests written!

Phew,

Ray

Leave a Reply

What is 4 + 7 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)

There are 101 ways to approach anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”

DAN PULHAM, DIGITAL DIRECTOR
TELSTRA