The most important skill in test automation

On LinkedIn, as well as on various test-oriented discussion boards there’s a lot of talk about the necessary skills one needs to have or develop in order to be a good test automation engineer / consultant / << insert job title here>>. Example questions asked can be ‘What language is useful to learn?‘ or ‘How do I automate fancy technology XYZ using tool this-or-that?’ (too many hits on LinkedIn to count, often related to Selenium).

Another perspective on the discussion on skills needed for successful test automation is whether you’re best off being – or employing – a developer with a testing mindset or a tester with development skills (I’d go with the latter).

However, in all those discussions, one vital, even essential skill everybody in test automation should have seems to be overlooked again and again:

Knowing what not to automate.

Honestly, some of the questions that pop up.. ‘How do I check the values on this pie chart with this tool?’ ‘How can I have my test script read an email using Outlook?’ Seriously? Why not just do a quick check on the underlying values (in a database, for example) instead of spending days developing a buggy test script that performs the same check, only slower?

In the wise words of Alan Page: “You should automate 100% of the tests that should be automated“. No more, and if possible no less either. But, when in doubt, it’s probably better not to automate a test that should be automated than to automate a test that shouldn’t be.

Still thinking about automating that Google Maps / Google Docs user interface check? Then please also consider the following likely outcomes:

  • You’ll probably introduce a lot of required maintenance effort (the Google UI’s change often and are notoriously hard to automate)
  • You’re not testing your actual product (unless you work for Google, and in that case, you probably know about their APIs which are much easier and faster to automate)
  • You’re throwing away money.

Please, don’t become the world’s best automator of useless checks.

Book: Alan Page – The A word

When not working on testing and test automation myself, I like to read books, articles and blog posts that are related to my profession. One book I have recently finished reading is The A Word by Alan Page. Although it’s more of a collection of revised blog posts from his blog The Angry Weasel than a book, it’s been a very interesting read nonetheless.

For those of you that aren’t familiar with his writing, Alan writes a lot about his experiences with testing and test automation. He is pretty well known for his skeptical view on how a lot of people see automated testing as the solution for everything, especially when it comes to GUI-based test automation. Although I do tend to write regularly about test automation using Selenium, I am not a big advocate of using UI-based test automation tools for all things test automation related myself (see for example this post). Therefore a lot of things covered in The A Word resonated with me and I found it a very pleasant read, although it is rather short at around 70-80 pages.

Book cover for The A Word - Alan Page

I wholeheartedly recommend this book to anybody that has anything to do with test automation, as Alan offers valuable food for thought for test engineers, test managers and all others doing or relying on automated tests. It might just make you think about whether you’re doing the right stuff and doing your stuff right..

The A Word is available on LeanPub. All profits go to the American Cancer Society, so that alone should be a reason to pick it up and leave a donation.