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.

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!



Leave a Reply

Your email address will not be published. Required fields are marked *

fifteen − 9 =