Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Why it's (still) so difficult for testers to learn test automation

public://webform/writeforus/profile-pictures/bas.jpg
Bas Dijkstra Test automation speaker and writer
 

As a test automation consultant and technical trainer, I've helped many testers take their first or next step in the world of test automation. I've seen many testers grow from test automation novices to seasoned veterans in the field. However, I've also seen a lot of them struggle.

Here are some of the root causes of these struggles, along with my advice on how to overcome them to become truly proficient in test automation.

Test automation absolutely requires software development skills

As the adage goes, test automation is software development. Creating test automation solutions that are reliable, that are maintainable, and that scale requires good software development skills, and that means that test automation engineers should have a decent grasp of what it takes to write software.

This doesn't just mean that you should be able to write code in a language such as Java, C#, or Python, but also that you should understand software development patterns such as SOLID and be able to apply the four pillars of object-oriented software development (encapsulation, inheritance, polymorphism, and abstraction).

The problem is that it takes time to understand these principles, to be able to apply them, and to know when and when not to apply them. And do not be fooled by low-code tool vendors' claims that you do not need to be a developer to use their software. These tools typically are nothing more than an abstraction layer on top of the code.

While I have no problem with this category of tools (there are some great ones), using them does not absolve you from applying general software development principles and patterns. Ignore this advice at your own peril. You will eventually paint yourself into a corner, with a mountain of hard-to-maintain low-code automation to deal with.

My recommendation: If you want to get better in test automation, study the fundamentals of (object-oriented) software development to help you craft better test automation solutions. Here are some good resources to help you on your way:

Experience with a just one tool, library, or language is not enough

Once you know how to wield your tool or language well, there's still more to do. Just as a carpenter can't build a table with only a hammer, you can’t be a versatile test automation engineer if you only know how to use a single tool, library, or programming language. You need knowledge of a variety of these tools to know which of them (or which combination of them) is the best choice to solve a given problem.

This knowledge extends beyond the realm of test automation tools. For your tests to run and be used often and effectively, you'll likely also need to know a thing or two about the tools that allow them to run like that. These include version-control systems, continuous integration orchestrators, and mocking tools. The list goes on.

My recommendation: While knowing how to handle a specific tool properly is a good start (again, that includes knowing how to apply good programming practices when doing so), get a decent grasp of at least one tool in every of the following categories:

  • Unit testing frameworks (JUnit or TestNG for Java, NUnit or MSTest for C#, pytest or unittest for Python, etc.)
  • API testing libraries (REST Assured for Java, RestSharp for C#, requests for Python, etc.)
  • UI testing libraries (Selenium, Cypress, Playwright, WebDriverIO, etc.)
  • Mocking libraries for unit testing (Mockito for Java, Moq for C#, mock for Python, etc.)
  • Mocking libraries for integration testing (WireMock, Hoverfly, etc.)
  • Version-control systems (Git is your best bet)
  • CI orchestrators (Jenkins, GitLab, Azure, DevOps, etc.)

That is quite a long list, but the reality is that there’s no road to overnight test automation success. My best advice is to learn not only more about the tool itself, but the principles behind the tool as well (What does it do? How does it work? What is its place in the wider test automation spectrum?), since this makes picking up a new tool (or even a similar tool in a new programming language) much easier.

Take small steps and you'll get there, eventually. Even a journey of a thousand miles begins with a single step.

Learning material often covers only the basics

When you start your test automation journey, or anytime you want to pick up a new tool or language, there is plenty of content available to help you get started. It doesn't matter if your preferred method of learning is by watching videos; reading tutorials, blog posts, or books; or attending a live training course. There is bound to be something that guides you in taking your first steps.

However, most of the material doesn't go beyond the basics, and real life often doesn't look like the situations you'll encounter in an article or training course. Content producers and trainers often do this intentionally; they are trying to teach a concept or principle, and that's much easier done when the example, exercise, or business case is small. When you try to apply what you have learned in real life, you might struggle to see the forest for the trees. The project or test automation suite you have to work with on a daily basis is likely to be much larger than what you've been working with in your learning journey.

My recommendation: If the problem is large, make it small. Break down the challenge you're facing into tiny steps and complete these one by one. Make sure you've completed a step successfully before taking on the next. Don't be afraid to ask more experienced colleagues for help or a review, and try to understand not only how something is done when you complete a step, but also how that step contributes to the overall solution. Nobody expects you to be an expert right from the start.

You might run into a situation where it is hard to get the time and attention of your more experienced colleagues. Senior automation engineers are scarce and typically have a lot of work on their plate, as do developers (don't forget that they can often help you, too). If you notice that it is hard to book time with them, don't get stuck for too long trying to do it all on your own. Working together (pairing or mob programming) is a much more effective way of getting things done and sharing knowledge and experience.

In the end, one of the most important responsibilities of any senior engineer is to help others get to their level, too.

Two steps to smoothing your transition

Becoming an experienced test automation engineer can be a long and bumpy road for many a tester. However, by following the advice I've laid out above—focusing on patterns and principles over tools and tricks, and breaking down big problems to smaller and more manageable ones—you will be well on your way to becoming a test automation veteran yourself.

Keep learning

Read more articles about: App Dev & TestingTesting