Test Automation Engineers: Focus on the Forest, Not the Trees

These days, a lot of development organizations are focusing on delivering software in ever-faster increments. However, in speeding up delivery, teams don't want to make too many concessions on the quality of the product they deliver. Many of these teams are learning that test automation, when done well, can help them to get at least some level of confidence that the software they're about to ship meets a certain level of quality.

This increased interest in test automation creates a demand for test automation engineers, and for resources that can help them advance their testing expertise and efforts. Some engineers choose to pursue self-learning through online tutorials, YouTube videos, and platforms such as Test Automation University. Others, who are often (but unfortunately not always) supported financially by their employers, attend one or more classroom-style training courses.

The Downsides of Taking a Tool-Centric Approach

Having been in the test automation field for 14 years now, not just as a consultant but also as a trainer, I've seen many people starting out on their test automation journey by picking a specific tool (or a specific programming language, or a specific technique) and then learning as much as they can about it.

There is a risk associated with this approach, however: if you're only proficient in a single tool, you'll probably try and solve any problem you're confronted with using that tool. Or, in other words, if all you've got is a hammer, everything suddenly starts to look suspiciously like a nail. This approach is problematic. It doesn't matter how useful the tool, or how well supported it is in your company and the larger testing community. You’ll still confront limitations because:

• The tool you're using might not be the most efficient tool to solve the problem at hand, leading to subpar test automation implementations.
• No matter how much a vendor may claim their tool can “do it all,” in general, most multi-purpose tools are average in specific areas, at best. In my opinion, the best tools do one thing and do it really well.
• Your next project, or even your next job, might require you to use a different tool. A focus on a single tool can effectively rule you out as a candidate for a large percentage of potential new projects and positions.

The problems above, I think, make it clear that you shouldn't just focus on a specific tool, or a particular language for that matter, when you're learning about test automation. Please note that I don't want to say that tool- or language-specific training should not exist, far from it! It's incredibly valuable to have deep knowledge about a certain language, framework, or solution. However, as a test automation engineer, you should be able to pick or craft the most efficient and effective approach to a specific testing or automation task, and that requires broader and more fundamental knowledge than only knowing about all the different features of tool X or language Y.

Focusing on Principles, Not Tools

To become a well-rounded test automation engineer, I think it is really important to focus on the principles and patterns that are the foundation of many of these tools and languages. Let's take a look at a couple of examples:

• Instead of saying “I want to learn how the page object pattern (a popular design pattern for Selenium-based tests) works,” try and learn about encapsulation, one of the four pillars of object-oriented programming. Encapsulation is defined as hiding the internal workings of a class and only giving access to this class through public methods. You'll quickly see that the page object pattern is one of the many applications of the encapsulation principle. However, while page objects are (sort of) limited to a single tool and a single type of tests, encapsulation appears everywhere in both test and application code, and is therefore a much more versatile and valuable piece of knowledge to have.
• Instead of saying “I want to learn how to use REST Assured for REST API testing in Java,” also learn more about how APIs work, how they are used in software, what to test for in APIs, and what types of tools there are to help you perform those tests, before zooming in on a specific tool and language. (For more on API testing, be sure to check out our blog post on using a model-based approach to API tests.) You'll hopefully see that there is more than one way to get the test automation job done, and that there's a place and context for almost every tool out there.

I could go on, but I hope that the examples above prove my point here: studying principles and patterns is likely to be much more valuable, especially in the long run, compared to limiting yourself to a single tool or platform. It will give you the experience, the ability, and the confidence to pick the right tool for the job whenever you're facing a testing or automation challenge. It will also make you a much more versatile test automation engineer, and that will be a big advantage if you're ever looking for a new project or job.

As an added benefit, knowing about these underlying principles and patterns makes it much, much easier to pick up a new tool or even an entire language. I can personally vouch for this, having worked in this field for 14 years now, and having worked with a wide range of tools and programming languages.

Conclusion

Consider this analogy: would you trust a carpenter that turned up with nothing more than a hammer when you want them to create a new cupboard for your kitchen? I hope not. So why should we as test automation engineers do exactly that? Study the patterns and principles that are the foundation of our trade, not just the tools that do the work. You'll be a much more valuable addition to your company for it.

Interested in learning more? Be sure to check out my blog post on test automation.