In today’s fast-paced software development and delivery world, as a software tester, it’s increasingly important to have at least some basic knowledge about test automation.

I’m glad to see that most software testers now seem to realize this, and people regularly ask me where they should start when taking the first (or the next) steps on their journey to become more proficient in test automation.

Usually, this question takes the form of ‘what tool do I need to pick up first?’ or ‘what programming language should I learn?’. My typical answer to those questions is either ‘it depends’ or ‘it doesn’t really matter’.

Since that’s not always the actionable answer people are looking for, I thought it would be a good idea to outline what I think constitutes a good learning path for anybody looking to become a (better) test automation engineer. It also gives me something to refer to whenever I get this question again in the future 🙂

In my opinion, and this has been backed by several clients I’ve worked with in the past, a solid learning path for test automation engineers (to be) should cover a variety of subjects.

Software testing

Test automation is the use of tools to help testers perform their software testing activities more efficiently. So, if you want to learn how to be a test automation engineer, you’ll need to have a solid understanding of what software testing is and how it is performed. Only then can you make an informed decision as to what parts of the spectrum of software testing activities you might want to perform more efficiently by using tools.

There is no either/or here, no ‘manual’ versus ‘automated’ testing. There is only testing, and some activities in testing can be better or more efficiently performed by tools. Others can be done better (or only) by people.

I can personally vouch for the Rapid Software Testing course as developed by James Bach and Michael Bolton as a great course if you’re looking to become a better software tester, but there are many other courses on the market that I’ve read good things about, for example the ‘Agile Testing for the Whole Team‘ course developed by Lisa Crispin and Janet Gregory.

Software development

Not only does testing, and by proxy also test automation, support software development, test automation in itself is software development, since you’re creating software to help you test better or more efficiently. At the very least, you’ll need to be comfortable around the concepts of parameters, methods, variables and control structures.

One step up, it’s also really useful if you’re able to read and understand application code, so that you can discuss its workings with the developers who created it, or to find the root cause of a defect you’ve seen pop up.

And if you want your test automation code to be well-structured and maintainable, it’s probably a good idea to study the four pillars of object-oriented software development (encapsulation, inheritance, polymorphism and abstraction) and how applying them can help you create higher quality test automation code. This video by Angie Jones provides an excellent explanation of how these principles can be used in test automation.

Oh, and please don’t think that you can skip this subject because you’re using a low-code test automation tool. I see those tools as an abstraction layer on top of coded checks, which means that even when you don’t actually write the test automation code, knowing how to apply these patterns and principles will still help you create more robust test automation that is easier to maintain.

This section also provides the rationale to my answer of ‘it doesn’t really matter’ when testers ask me what programming language they should learn.

The underlying concepts and principles I’ve mentioned here can be applied to all (or almost all) current programming languages, which means that if you understand them, it’s surprisingly easy to switch from one programming language to the next, or to pick up a new programming language. The difference between one language and the next is then mostly syntax and supporting tool sets (such as dependency managers and compilers / build tools).

Test automation strategy

Over the course of my career, I’ve seen and contributed to many a failing test automation project. Often, the reason for these failures has been the lack of a solid test automation strategy. And while ‘strategy’ might sound like ‘lots of documentation and meetings’, it doesn’t have to be. A good start would be to find an answer to these questions:

  • Why do we want to apply test automation in the first place (what problem are we trying to solve)?
  • What are we going to automate (which tests and test types, what’s going in the build pipeline)?
  • Who is going to create and maintain the test automation (and do they have the right skills)?
  • When are we going to create and run our tests (and how do we make sure there’s enough time allotted)?
  • How are we going to implement our tests (this includes but is definitely not limited to which tools are going to be used)?

If you want to avoid the failures I made in the past, I highly suggest you get comfortable with asking and getting answers to these questions, and acting accordingly.

Test automation tools

For a test automation engineer, it’s incredibly useful to be comfortable around several tools, and preferably also with more than one programming language. Remember: if you study the underlying principles, picking up a new tool or language probably turns out not nearly as daunting as you think it might be!

Try and avoid becoming a one-trick pony. Don’t become just a ‘Selenium WebDriver in Java’ engineer. By all means become proficient in Selenium WebDriver or Java (or any other specific tool or language), and maybe even an ‘expert’ (although I find that term subject to strong devaluation), but make sure that you’re more versatile than that. You never know what your next project or job will require.

There are many courses focusing on test automation tools and programming languages out there, so many that it is hard for me to single out one or two. The only thing I can recommend when you select a course is to find out (ask!) whether or not the course also covers the underlying principles and patterns, or if it merely teaches you to perform tricks with a tool. You know what they say about a fool with a tool…

Test automation engineering

One more subject I believe a test automation learning path should cover is engineering, by which I mean that a test automation engineer should also be proficient in tools and concepts that go beyond creating automated checks. Automation is much broader than ‘just’ these checks. Some examples of these tools and concepts are:

  • Build tools and package / dependency managers (think Maven or Gradle for Java or NPM for Node.js)
  • Version control systems (Git, TFS, Subversion, …)
  • Continuous Integration platforms (Jenkins, GitLab, …)
  • Mocking / stubbing / service virtualization tools (WireMock, Hoverfly, …)

and the list goes on. In any given test automation project, it’s likely that you’ll have to use, or will benefit from using) at least one of these types of tools, and therefore it makes sense to get acquainted with them.

Wow, that’s quite a list! But I never said that becoming a test automation engineer was going to be an easy ride, or something you’ll learn in a day or two. More likely, it’s going to be a life-long learning journey…