If you’re ever around Greg Paskal, be sure to have a recorder or a pen handy. You never know what new automation term he’s going to coin or testing metaphor he’s going to let loose. That's why I love having him on TestTalks; he’s one of my more quotable guests.
In the most recent Test Talks episode, Greg came up with a few cool test automation metaphors I wanted to share with you.
Selenium Syndrome
During our conversation, Greg defined what he calls the “Selenium Syndrome.”
He hears “Selenium” thrown out at conferences pretty frequently. At a recent workshop he attended, for example, he noticed that a large number of folks were sent there by their management people to learn Selenium with the expectation that after a single, one-day workshop they would come back and immediately begin building out their test automation. The sad thing about it was that many of those attended had never opened a command line before.
Greg explained that “Selenium” is a common term that people will throw out to mean that they're expected to do automation – and that it's an easy thing to do.
Selenium is Not an Automation Tool
Even the Selenium website unintentionally sets up an unrealistic expectation in that it refers to Selenium as an “automation tool,” when we know it's a lot less than that.
Greg says likens it to a situation in which someone comes to you and says, “Hey! Let's go for a ride in my Goodyear!” You would probably answer, “Your Goodyear?” Selenium is like a tire on a vehicle. It's a small piece of a much bigger set of tools that are required to perform the task; in our case, test automation.
Test Tool Fan Boys
I’m probably as guilty as the next guy when it comes to this problem. We easily fall into the trap that says if we love a particular tool that it must also be the best or right test tool for everyone else. When we become fan boys of a particular tool or technology it can cloud our judgment and cause us to recommend it to others even if it’s not the right fit for their particular situation.
We're actually doing a disservice to the engineering field of automation when we begin to gain followers by arbitrarily advising them to use a certain tool.
Greg sees this as a challenge; he believes we need to be able to step back from what we personally believe are the right tools for us and take some time to consider (and even help) those we advise to assess what the right tool(s) for them are.
Whats the Best Test Automation Tool
Greg and I have both used HP/Mercury tools for many years and we love them. But when recommending tools to others it's best to stop and consider what might be best for others who are about to embark upon the journey of writing automation for their company.
Greg also mentioned that as someone who has a background working with HPE Tools and has been using Selenium for a year and a half, he’s found he can perform the same exact test automation with HP. In some cases, he adds, HP can even do it better.
There are some tools that are missing from the Selenium landscape. For the past few years, Greg has been using Selenium with Ruby. And even though his team is making some progress, the fact is that it takes an enormous amount of extra effort in the Selenium space than it does with an off-the-shelf-tool.
It's as simple as that.
