You are here

With test automation, it's not the tool that matters

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

People often ask me about the best tool or language to learn when they are starting out or trying to advance their career in test automation. Should they learn Java? Do they need training in Selenium? What about tools such as Cucumber and SpecFlow?

The truth is, it doesn't really matter. This answer may surprise you, so below I'll take you on a deep dive into the rationale behind my answer — and what you should focus on instead during your journey to become a better, more versatile test automation engineer.

But the main reason it doesn't matter is that focusing on one tool or programming language limits your options. And it limits the value you can provide to your employer or to your client.

Here's how such limitations manifest themselves, and how to avoid having it happen to you.

Gartner Magic Quadrant for Software Test Automation

Tools come and go, so focus on skills

I've been active in the test automation field for well over a decade. In that time, I've seen many popular tools come and go. Some have been only briefly popular, while others emerged, slowly grew in popularity, and are still in use.

Eventually, though, all tools become outdated, get replaced by better alternatives, or stop being maintained. So if you focus on learning and mastering the ins and outs of one tool, every few years, you'll have to shift your focus and start learning something new.

Principles and patterns last much longer

You might feel overwhelmed by the vast number of tools and languages that are out there for you to learn more about, as well as the fact that new ones are constantly emerging. But there is good news as well. Many tools are based on the same underlying patterns or principles. Focus on those, not the tools. 

Here are a few examples:

  • Test automation tools Cypress, Selenium WebDriver, Protractor, and CodeceptJS (and many similar alternatives, both open source and commercially licensed) all operate under roughly the same principle. They interact with a browser and search the Document Object Model to identify and interact with elements on a page.
  • Commonly used patterns, such as the page object pattern and the screenplay pattern, are nothing more than applications of some of the underlying principles of object-oriented (OO) software development. For example, the page object pattern is a form of the encapsulation pillar of OO, and the screenplay pattern is an application of the five SOLID design principles.
  • Nearly all programming languages used in test automation are OO by nature. This means they all share common concepts such as objects, methods, and parameters and feature the four pillars of OO: encapsulation, abstraction, inheritance, and polymorphism.

If you learn and understand these common principles and patterns that form the foundation of so many tools and languages, you'll find that it becomes much easier to learn a new tool or language or to switch out one tool or language for one that is a better fit for your current project and organization.

[ Conference: ADM Summit 2019: Optimize Your Deployment Pipeline ]

If all you have is a hammer ...

Many people who master a single tool or a single programming language tend to adopt an attitude of "Here's a solution; now let's find some problems to solve." This is also known as the "If all you have is a hammer, everything looks like a nail" phenomenon.

This often leads to suboptimal situations, as is clear in the following examples.

The problems with a UI-driven test tool

If all you master as a test automation engineer is a user interface-driven test automation tool (such as Selenium WebDriver), you'll be tempted to automate all of your tests through the user interface, even if the logic you are verifying does not reside in the UI at all.

This, in turn, leads to shallow feedback, because the added UI layer—or any unnecessary layer, for that matter—hides valuable information in case something goes wrong during test execution.

It also creates additional maintenance overhead. The more layers you involve in your test automation, the more likely it is that a change in any given layer of the application under test affects your tests. The UI layer is especially prone to this phenomenon, but it applies to all application layers.

A single-language focus can also harm your work

If the developers in your team all work, for example, with JavaScript and PHP, but the only language you know for test automation is Java, you'll likely run into difficulties soon.

For starters, it's unlikely that your developers are willing (or able) to support you in your test automation tasks. It's also improbable that they will run your tests as part of their development and testing activities. That means those activities will be less effective. 

It also adds another platform and set of tools to maintain in the development team tool set and infrastructure and makes it difficult to co-locate your automation code with your application code.

Context is king

Want to become a more versatile test engineer? Understand that context is king. In other words, whatever you used in a previous team, project, or organization might not work for your current setting.

There are many factors that influence whether or not a given tool set or language is a good fit for any given situation, including:

  • The programming language and tool set used to build and deploy the application under test
  • The types of tests that you're looking to automate
  • Your skill set and level of experience
  • Tools that are used elsewhere in the organization, including any possible vendor contracts

When you learn just one tool or language, you limit yourself, as well as the context you're working in, in terms of versatility and the ability to change tactics whenever a course correction is needed.

So don't make it your goal to become a master of Selenium WebDriver in Java or a SpecFlow and NUnit expert. The tool isn't what matters.

Instead, learn to identify and to apply the underlying patterns and principles that form the foundations of many of today's tools and languages, as well as those that will emerge tomorrow. Do this, and you will become a much more versatile and valuable test automation engineer.

[ Partner Resource: Learn more about key trends in test automation. Attend the Performance Guild online conference, which runs from April 8-9. ]

Article Tags