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.

13 thoughts on “The most important skill in test automation

  1. True, a key thing to do with any automation implementation is to review the work load and determine what makes sense to automate or not. This is one of the toughest things to do, decide what not to automate. And that is because of the mentality of management and some other unknowing people that you must “automate 100%”. It is a myth that some people just don’t want to face up to and admit it just isn’t going to happen.

    I always tell clients that even before they write a line of automation code that they need to review things and categorize and prioritize along with removing uneccessary tests. Doing the front-end work as due dilligence will make things a lot more straightforward later on and keep things on track. It will allow them to have a better chance at success.

    • I wholeheartedly agree, Jim. Thank you for your insights. If there’s just one manager who thinks twice before yelling to automate it all after reading this, or one engineer who stands up against such a manager, I’m a happy person.

  2. Bas, you are taking examples of what i would call “extreamly human oriened” user interfaces. Indeed through decades developers are improving at building human oriented interfaces. But even with less human oriented interfaces – trying to teach computer to use those interfaces is to my mind a nothing but workaround. So you are saying that … understanding the above is a core skill. However strange it sounds, I tend to agree…

    • Hey Ainars,

      aren’t all user interfaces human oriented? Some of them do this more successfully than others (better usability, for example), but aren’t all user interfaces built in order to allow humans to interact with a software system?

      I’m not sure I completely understand what you’re trying to say here..

      • Actually i wanted to ask you to go deeper describing your vision of the skill.
        I’ve seen others writing about avoiding UI interaction in automated tests at all or follow some Pyramid logic. But I agree with you that understanding when to avoid computer-UI interaction is not a method, no “best practices” can help with those decisions.
        So the question is – how to learn and improve this skill especially for those with experience doing “100% test automation demanded by the Boss”

        • Hey Ainars,

          I think I understand what you’re saying now πŸ™‚ That’s a very good question.. How to be able to better identify which tests to automate and in which way. I’ll definitely put that on the list of future topics! Thanks again.

  3. Pingback: Testing Bits – 9/13/15 – 9/19/15 | Testing Curator Blog

  4. Hi Bas,
    πŸ™‚ Actually bas you said you are something like a freelancer.Does that mean when required companies call you and you then automate their scenario?if that is the case you use data driven framework and take input from excel and also implement page object model and to generate output use extent report?

    • Hi Sherin,

      I mostly work on longer-term projects (six months up to a year and a half). I’m not that far advanced that companies call me if they need work done, I have to do some acquisition myself. That’s fine though, the job market for test automation is pretty good over here at the moment.

      To be honest I haven’t used Selenium at all in any of my projects so far, everything I’ve written about it so far is experience I’ve gathered during hobby projects and studying.

  5. Hi Bas,
    As far as this post goes my opinion is all test automation
    guys have to be good manual testers first right?maybe i think i have to go back to some basic concepts of manual testing youtube tutorials to make my base strong πŸ™‚ .yes we just cannot automate everything good manual testing is really important πŸ™‚

  6. oh god delete my above two comments.sorry ok?
    Hi Bas,
    sorry if this is unrelated to your post ok?i believe every organization have their own methods to do testing.But whether it is manual testing or automation testing would it be good before we begin testing if we prepare an excel sheet where we manually input test scenarios and test cases to each sheet and then move on to testing?

    • Hi Sherin,

      that depends.. It’s always a good idea to have some common understanding of what is going to be tested, but that doesn’t have to be in the form of written out test scenarios in Excel.

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.