Automation Plan - Keep it simple

By Ray Claridge
Pin It

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!




  • Kevin Black said:  

    Great post! Good advice, especially the parts about identifying high risk areas and those with low expectations of changes.

    I'd love to see more posts like this one. Short and to the point! :-)

  • Ray - Testertroubles said:  

    Hi Kevin,

    Glad you like it. I try and keep my posts short and sweet and not too bogged down with tech stuff.

    Come back soon for some more posts

  • Lisa Davidson said:  

    Great post. I like your post and do agree with you, very well said.I trust mots QA Testing expert will appreciate your note. Thanks for sharing this.

  • A. Jacobs.Amoo said:  

    Nice Post Ray, keep it up...

    And by the way, i quite agree with your submission on automation, could not have put it in a better way


  • A. Jacobs.Amoo said:  

    Nice post Ray, could not have put it in a better way myself....

    Keep it up

  • Software Testing said:  

    It is pretty interesting to read about automated testing, but I am sure developing such system will take time and cost compare to have a testing team or outsourcing testing process. Anyhow, that is good place, you have given in detail, but I still doubt whether it is possible to implement successfully. Failure may be high compare to human testers.