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.