Test automation? The tool is not important.

As a dedicated test automation craftsman, I read a lot of blogs, spend a lot of time (too much, maybe?) on social media like LinkedIn and Twitter and generally enjoy discussing test automation with my peers and learning from them. While doing so, there's one thing that keeps striking me as odd, though. When it comes to test automation, and specifically to people that want to break into (or get ahead in) the field, there's one mistake that I keep seeing being made:

The relentless focus on tools.

Please don't get me wrong, I am fully aware of the fact that test automation is all about tools, in the end. What I'm referring to is questions like:

• I want to learn test automation, which tool would you recommend and why?
• I've been given the task of automating < insert task that's a questionable fit for automation at best >, what tool is best for doing that?

I'm not trying to blame or shame the people that are asking this type of questions here, they probably mean well and are looking for a genuine solution to their test automation challenges. The main gripe I DO have with these questions, however, is that they directly zoom in on the 'how?' to perform a certain test automation-related task, or in other words, they immediately put the spotlight on specific tools. By doing so, the far more important questions of 'why?' to use automation in the first place and 'what?' to automate and using what approach are thereby being stepped over. Yet it's being able to successfully answer the 'why?' and the 'what?' that lays the foundation of any successful test automation implementation.

And it's not just the practitioners themselves that I feel could benefit from taking a step back and asking 'why?' and 'what?' to automate before they're even starting to think about the 'how?'. The people and organizations at the other end of the table (employers, recruiters, consultancy agencies, training providers) are just as, if not more, guilty:

• Job openings and project offers for freelancers are loaded with lists of tools that an applicant should master, and candidates are rejected if they don't tick all of the boxes. Some examples I've seen (and a free hint for recruiters and hiring managers): you're not 'automating your tests using Cucumber', so please don't state that ever again. Nor should you reject the candidate with years of experience in SpecFlow but none with Cucumber, just because that doesn't tick your box. Look beyond the tool and see what problem needs to be solved.
• There are myriad training options available for people that want to get started with or improve their proficiency in tools like Selenium WebDriver, yet I see almost no professional training being offered that teaches participants to ask for and answer the 'why?', or to dive deep into an application and determine 'what?' the most efficient approach for applying automation to that application is. This training course might be a notable exception (I haven't taken it myself, so far, so I can't say this with 100% certainty. Also please note that I'm in no way profiting from mentioning this course).

I could probably come up with more examples, but the overall point I'm trying to make here is simple:

The tool is not important.

Why you would want to use a tool to support your testing efforts, and what it is exactly that you want to do with this tool, now that's what IS important. Yet those are the questions that are still too often forgotten or skipped. The strange thing is, other crafts seem to have mastered this a long time ago. For instance, would you trust a doctor that does not ask what is wrong with you and what the symptoms of your ailment are when you're seeing him or her for the first time? What would you think if, instead, he or she would say ‘Please lie down over there, while I prepare the anesthetics.’ moments after you come in?

Sure, it could be that your doctor coincidentally is also a psychic (or someone with a gambling problem) and knows exactly what's wrong with you and what the best possible treatment is. But that's not very likely, now is it? I can only speak for myself, but when I see a doctor I'd like him or her to ask after the reason 'why?' I'm paying a visit, as well as after the 'what?' ailment I'm experiencing before jumping to conclusions on 'how?' to treat me best.

Why is it, then, that the test automation field is still so full of people that are all to eager to do exactly that? Jumping to conclusions and trying to 'cure' everything with a 'healthy' dose of Selenium-based tests, for example? Or steering people into learning one specific tool or programming language, when there's a far broader level of test automation base knowledge and experience that should be covered first?

Why is it that we’re still too often directly resorting to discussing which tool to use, bring, buy or build when it comes to test automation? Wouldn’t it be far better if we asked why we need automation in the first place, and what exactly it is that needs to be automated, and in what way? I think it would lead to far better and more effective automation, since because we made sure we'd do it for the right reasons. Plus, it would probably create a lot of buy-in with stakeholders in the process, as well as protect the craft and the software development world from a lot of useless automation efforts. I don't see how that could be a bad thing.

In short, I'd like to see a lot more people dealing with test automation studying, discussing and discovering the 'why?’ and ‘what?’, before firing up their test automation tool or IDE of choice and take a shot at the ‘how?’. That’s when the tool becomes important. Until then, it’s not.

About me: I'm an independent test consultant who loves helping clients improve their testing efforts through smart application of tools. You can contact me here on LinkedIn, via @_basdijkstra on Twitter or through my blog OnTestAutomation.