A lot of managers wants their testers to pick up test automation. Well intended, and they are also willing to give them time to experiment with the latest automation tool (Cypress.io anyone?).

Now, when a manager thinks test automation he or she probably imagines it mostly being learning the tool, picking up the syntax of the test tool and trying out a few things.

For some of us it is.

The problem though is that on a sliding scale, testers tend to end up in two camps. The ones that have done test automation in their past, probably still do it, and are keeping their skills up-to-date in this particular domain.

Then there's the ones that never automated... anything... ever...

(<Disclaimer> Of course there is a sliding scale in between these two groups that people fall into, but a fair few tend to end up more towards one of the two groups mentioned above... it's a gray zone, not black and white.</Disclaimer>)

If I look to myself, then whenever a customer/manager/project lead asks me to start automating tests for our product or whichever feature we happen to work on in this sprint then I have spent my whole career doing test automation on and off in various domains (telecommunications, cloud based services, crypto currencies, mobile device, and more...) in various contexts (Different Linux distro's, Solaris, Windows (sigh...), Webb, Microservices...), and I've been using different tools for different kinds of tests (Homegrown internal test tools and frameworks, custom written C-modules in the Linux kernel, xUnit, JMeter, Protractor, Cypress.io, GUI test automation, REST API test automation, and on and on...).
I've programmed in various languages over the years (Python, Java, C++, C, Symbian C++, Perl, PHP, Javascript, Bash, VB.NET(Yuck yuck yuck!!!)).
So when I'm asked to pick up a new tool, then well... it's mostly limited to learning that new tool and how it's best being used for my context.

But when a tester who have never automated before hears this, then they see this:

It's the looming "Mountain of test automation doom".

It looks big, there's sharp cliffs, mysterious things (dragons?) hiding behind the mist, and surely we're not seeing the whole thing right?

What I'm trying to get at is that for a tester that's never done test automation there is... well... more than just test automation that needs to be learned.

Let's say we're working in a normal web-shop writing some sort of web GUI, communicating with a back-end service, for instance a REST API.
Now that person has to be familiar with:

  • A test automation framework like Cypress, Protractor, Selenium or something else.
  • HTML, DOM elements, CSS selector strategies, Page-objects
  • Tests needs to be written in some sort of language, likely Javascript, but maybe Python or some other language is being used internally. This means the syntax of the language, the tool chain, how to build, setting up the environment.
  • Oh that's right, installing an IDE of some sort to write your tests in.
  • Package management like NPM, concepts such as package.json vs package-lock.json
  • Likely a task runner like Grunt.
  • Building... why have our developers turned on this lint-thingy, and why is babel complaining about transpiling?
  • GIT or some other version control system. Checking out code, making commits, pushing to the remote server, potentially having to solve merge conflicts. Oh I need to create a pull request and have developers review my code. Wait what!? How do I update my pull request now that they have feedback that I need to fix. What do you mean the master branch is ahead of my own branch and how do I update my branch? And what on earth do you mean by me having to squash the commits?!
  • Working in a terminal for starting the development webb server, running the tests and all sorts of other tasks.
  • Potentially how to SSH into the remote server to inspect log-files from our test run that failed. What are environment variables and how do I set them in bash?
  • If the back-end is to be inspected or maybe used to fast-forward the desired state of the application we're testing, then JSON-data and REST calls are likely.
  • What's a REST API, how to make requests... and... wait there's more than GET requests?I need to know of POST, PUT, DELETE... and there's more of them?
  • Logging in to the Jenkins server to read the log-files from test runs, maybe manually trigger new test runs.
  • And wait.. what!? Why are you complaining on trailing white-spaces in my test automation files or that I'm using windows newlines in the code review? And what do you mean I can enable auto-fixing off those in my IDE?

As you can see, for someone that has never done test automation, or maybe just did it a long time ago in another domain/context, there is so much more than... well... test automation.

The problem is that most of the time a manager is not aware of this and only thinks "test automation".The employee is nervous and don't even know where to start, showing that he or she doesn't know. That mountain of test automation doom sure looks insurmountable.

Perhaps you're lucky and have fantastic developers in your team that are not only willing to help you, but who does it with a smile and doesn't make you feel stupid for not understanding the difference between ECMA-script 5 and 6 and why you absolutely should write your tests directly in Typescript instead to get type safety and intellisense in the IDE.
Maybe you don't have to have a technical discussion with your developers over why we can't test everything with unit tests and why we actually do need some GUI tests (never been there right...?)

But it also requires you to be willing to ask for help, showing that you don't know something, and a willingness to learn. That requires a team and environment that is a safe place where we feel confident asking these questions. They sure aren't a given in any workplace.

So as a manager, the next time you wan't your testers to pick up test automation, just know that it's more than just test automation, and you need to be willing to put aside the time for it, and respect that maybe not everyone wants to or can pick up all the things mentioned above (and I haven't even mentioned the lost time/opportunity to the testing not being done and instead spent on the automation).
And remember that different people will start off from different places and have more or less to learn before they can get to the.. "test automation".

It's incredibly hard for a person to pick up all the things necessary for test automation in the sprint, alongside all the other work we do concurrently, the features that needs to be tested that our developers delivers to us.
Expecting the employee to pick it up on their own time outside of work is just unrealistic and not even remotely fair to people who have families, private lives, dinners to make and so on.

There are ways that we can make that mountain a little bit less intimidating, scatter that mist into the wind and make the whole problem easier to approach and I plan to write about that in coming articles. For now just remember.

"Test automation is more than just test automation"