Episode 010 - The Automate or Die Special - The Evil Tester Show

In this podcast we consider the concern that people need to learn to Automate or they will not have a testing career

Subscribe to the show:

Watch on YouTube

Show Notes

I receive a lot of concerned emails and messages from testers. People concerned that their testing skills will not be enough to keep them in work and that the future revolves around automation which they don’t know how to do. No programming experience. And should they learn API or UI? What programming language should they learn? People do feel that their career is at risk.

And that’s what I cover in this podcast.

Disturbing Trend

I think it is a slightly disturbing trend that automating is so tied up with testing.

Because it almost doubles the time it takes to learn ’testing’ - you have to learn to automate, and code, and test. And learning how to test requires that you learn other parts of the development process - requirements, management, communication, process design, architecture. And there is a lot to learn from other disciplines: math, sociology, psychology, psychotherapy, etc. There is enough to learn and study already to become good at testing.

Personally Take Long Term View

This is also why we need to take a ’long view’ of our testing careers. Over 20 to 30 years, you can spend 5 years on each main discipline and become pretty good at all of them.

But recruitment often takes a short term view and requires expertise in all of this in 3 - 5 years. Recruitment is broken.

Automation and automatability are independent of testing. Sometimes we conflate them because we want to automate in support of testing so view automating through a testing lens. But we don’t exclusively automate in support of testing so both automating and automatability exist independently of testing.

The coding skills required to automate for testing are often viewed as simpler than production code. This is not true. To write code for automating we are taking a strategic view of automating and that requires production level coding experience: abstraction layers, unit testing, TDD, architectural patterns.

I do think learning how to code is useful. It has been beneficial for me. But I also had 3 or 4 years commercial programming experience before starting to learn testing. And informally 6+ years messing about with computers and programming prior to that. I had the time to develop skills and I enjoyed it. No-one should be forced to learn this.

When employers mandate coding as a requirement for testing it means they don’t understand the value that testing can bring. And while it seems hard that you won’t get a job with that company, you are probably better off not getting a job with that company. Hopefully there are enough companies not having coding and automating as a job requirement to allow you to progress your career. But it does seem concerning that so many companies do require this.

Automating Does Not Have to involve code

There are commercial tools that allow us to achieve automated execution aims without requiring extensive training and practice and experience in programming.

These can be a viable alternative to requiring all your staff to learn how to code and they can be used strategically to achieve your aims for automating.

The tools have changed over the years and I’ve been looking at a few tools recently that are affordable and do work.

My views on this have changed. Commercial tools used to be incredibly expensive, locked down, inflexible and still required a lot of coding experience, but the coder was hamstrung by the environment. Now the technology is catching up with the user experience and allowing people to automate without the emphasis on coding experience.

How do I get a job automating without experience?

Make your learning public: blog, github.

Explain what you have learned.

I recommend starting where you are.

i.e. if you are testing APIs, then learn to automate APIs. If you are testing web apps, then learn Selenium. If you are testing desktop apps, then you can still learn Selenium with WinAppDriver.

And start by automating to support your work.

Start tactically, rather than strategically.

tactically - getting something done fast which we might build on, but also might throw away or not share
strategically - committing to an approach that you will build on and maintain long term

Find a way to automate something that you do.

It doesn’t have to be:

robust
reliable
well written
fully automated

But it can support you.

I need to code. What programming language should I learn?

What language to learn?

Depends on:

what you want to do and
who you want to learn from and
who you have supporting you

If you can do this in your normal work and get support from people around you then choose the languages and tools that they know. Pair with programmers if possible.

Sometimes people don’t like asking programmers. I’ve found that programmers are happy to share their knowledge and help if you are actively learning and making progress on your own.

Start small.

I don’t have anyone that can help

If you don’t have that advantage then find a teacher that you want to follow their material and work through it.

youtube
online courses

At the same time… immerse yourself in that language. Blog posts. Twitter people. Books (o’reilly safari trial, use the library).

Read code

Immerse yourself in code.

Read code:

blogs
github
run other people’s code
hack about with other people’s code

Be prepared. Getting started is the hardest part

Getting started is the hardest part.

Scripting languages seem easy because of that, but all languages are complicated eventually, and when you start writing automated execution code strategically, you’ll be writing code.

If it is for career growth then you have the difficulty that people don’t really hire without experience so you have to demonstrate that experience.