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.
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 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.
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:
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.
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.
bizops.com is sponsored by Broadcom, a leading provider of solutions that empower teams to maximize the value of BizOps approaches.