This a good time to be working in test automation. Many organizations, wanting to deliver products at an ever-increasing pace while maintaining quality, are turning to this discipline. And with that has come an increased demand for test automation engineers.
This trend, in turn, is driving increases in test automation training courses targeted at building engineers' knowledge and expertise and organizations looking to further educate their employees in that field. This is a good thing; test automation is a craft, and as such it requires continuous learning and constant honing of your skills to become a true test automation master.
That said, the longer I've been in the test automation field, the more I realize that there's something inherently wrong with the way we train test automation engineers. The training offerings place a relentless focus on tools, with titles like "Selenium WebDriver Essentials," "Introduction to JMeter," "Advanced Cucumber." In some cases, you even have even an option to gain a "certification."
I understand that being proficient with test automation tools is a useful skill for a test automation engineer to have. After all, what good is a carpenter who does not know how to wield a hammer? But these tools courses teach you just one thing: how to perform very specific tasks with a specific tool. That's not going to cut it.
Here's how to clean up the test automation training mess.
What test automation is really about
We need to improve the current situation with test automation training, which is profitable in the short term but suboptimal in the long term. To do that, it's necessary to first see test automation for what it really is: 1) an activity that supports software testing and software testers, instead of replacing them; and 2) a software development activity.
Automation is for the testers
To train good test automation engineers, we need to teach what software testing is, too. Only then can they identify where test automation fits in the larger software testing spectrum, what activities testers perform can potentially be automated, which can sensibly be automated (there's a difference!) and how the testing process, as well as overall software development and delivery, can benefit from test automation.
There's a reason all medical specialists receive broad, generic base training for many of years before even starting to specialize in their desired fields of expertise. The test engineering community should start doing the same in our own craft.
Get your code on, testers
Once you recognize that test automation is a software development activity, you can see that well-trained test automation engineers need to have a solid grasp of common software development principles and practices. These range from basic object-oriented programming concepts, such as polymorphism, inheritance, and encapsulation, to common software development practices such as code reviews, version control, and continuous integration.
I'm not saying you should become an expert programmer. But if you're going to create solid, reliable, and maintainable test automation solutions, experience applying the aforementioned concepts and practices is a must. Failing to do this results in test automation systems that might work initially, but eventually suffer from poor maintainability and usability. And don't let marketing departments fool you: this applies equally to low-code and no-code test automation solutions.
Many other things are essential to creating and implementing a solid test automation approach, but they aren't taught in these courses. These include how to determine what to automate, and more importantly, what not to automate using that tool; what other tools are available, and the relative merits and drawbacks of each; and how to make sure that what you're automating provides value to the software development life cycle and the stakeholders in the development and testing process.
Would you rather have a carpenter who starts banging everything in sight with a hammer, or one who knows where nails should be applied, how best to use nails in the overall carpentry process, how those nails contribute to what's being built, and when to use a saw instead?
Beware the test automation training market
Don't blame the providers of these test automation training courses for this situation Apparently, there's a demand for them in the current testing market, and I know from firsthand experience that there's good money to be made in this type of training. But I've also seen the results of the relentless focus on tools in test automation training—and in the test automation field in general.
This focus produces test automation engineers who are highly skilled in a specific tool and subsequently spend much, if not all, of their time furiously automating anything in sight using that particular tool. They don't know to step back from time to time to assess whether there's a better solution to their automation problem, or if their automation efforts are providing the desired value. Their résumés consist of a long list of tools that they have worked with, without any further insight into what they achieved using those tools or which underlying problem they have solved in their test automation efforts.
Secondly this focus has had a negative effect on the hiring process for test automation engineers. Without people with a thorough understanding of the underlying principles of test automation and what it can and cannot do for you, all that's left for organizations and recruitment agencies that want to separate suitable candidates from all other applicants is to review years of experience candidates have with a given tool or range of tools, without regard for the more general skills that form truly valuable test automation engineers.
Go beyond the checklist when hiring
The hiring process today has been turned into a checklist operation, where organizations run the risk of missing out on a great hire, and automation engineers fail to land jobs that would have been a perfect fit, simply because they lack XX years of experience with a given tool. For example, I've people passed over for a job that required a certain number of years of experience with Cucumber, even though they had more than enough years of working experience with SpecFlow. While this might be an extreme example, it's clear that this tool-centered phenomenon is not a good thing for either side of the interview table.
This phenomenon isn't limited to classroom-style training. I've seen it happen in on-the-job training just as much, if not even more. Consultants or senior employees train people who are relatively new to test automation and the tool at hand by demonstrating and teaching them all the nuts and bolts of that tool. In so doing they disregard essential aspects such as "Why did we build this solution in the first place? What problem does it solve? What type of tests should (not) be automated using this solution?" and so on.
Get the training right and test automation will deliver
If you want to fix the way we train our test automation engineers, lose your fixation on tools and start seeing test automation for what it really is: a craft that requires many more skills than simply a proficiency in tools. Only then can this discipline live up to the expectations that come with test automation.
Fortunately, I am relieved to say, I am not alone in this view. I have seen several training courses recently try to address this problem. We need many more, however, and the sooner the better.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
