Right, let’s kick this off by stating that the Selenium family of tools are the de facto standard in web testing. It has not gained that position by not being powerful, flexible, and a great tool. It is quite simply a beast in web test automation. But that is not to say that it is everyone’s particular brand of gin; it is not right for everyone. Of course, this opening gambit is somewhat at odds – and clearly more nuanced – than the title of this blog post, but hey, the title got you here.
Another point on the title: are there many actual, meaningful limitations to the framework? Selenium cannot take a dog for a walk, that is clear, but when it comes to web testing, Selenium is programmable, so if you have the skill, you can do it (there are many paid tools that have webdriver under the hood). But just because you can it does not necessarily mean you should – I could have a Wallace and Grommit style breakfast-making contraption; I don’t, but that’s mainly because my dog is not a great engineer.
If (unlike me with the dog), you have a team of highly skilled Software Test Engineers, you may think you are good with Selenium. But because Selenium tests are so engineer-centric, there are drawbacks:
Turkey is dryer than chicken, it’s a fact. Sure, you can do lots of things to make turkey moist, but you don’t have to do that with chicken. I have now annoyed turkey lovers as well as the Selenium community, and feeding the family with one chicken is becoming an issue. Selenium is difficult to maintain. Yep, you can metaphorically baste and rest your tests by using IDs rather than xPaths, having clean code etc. But, there is no escaping that Selenium tests have a tendency to be flaky and difficult to maintain. If you are, or can make use of, a great test engineer, maintenance issues can be overcome. But if other tools can unburden teams of maintenance overhead, why not use them and deploy any skill to other areas, like finding bugs?
End-to-end testing of business systems and processes stretches Selenium beyond its core functionalities. Selenium is designed to test the UI of web applications. You can of course extend Selenium with webdriver beyond it’s core functionalities, but just because you can… If there are tools out there that allow for robust, out-of-the-box, end-to-end testing, why not leverage them?
As has been discussed, harnessing the power of Selenium requires a lot of engineering skill, which is expensive. And this expense can by multiplied by the fact that tests are difficult to maintain. This is not to mention the fact that the infrastructure costs and the time it takes to set up all the dependencies.
So, if you can get something that delivers everything you need from Selenium, frees up engineering skill to concentrate in gaps other technologies cannot cover, is cheaper, and gives you a greater ROI, why wouldn’t you?
Now, let’s be frank: there have been a lot of false starts and broken promises in the world of codeless test automation. Indeed, before I was employed by Virtuoso, I was skeptical of a new, completely codeless testing platform. That was until I saw it in action. But it is now apparent to me that advances in Natural Language Programming, Robotic Process Automation, AI, and Machine Learning have made what is possible with codeless test automation unrecognizable. Authoring robust tests that actually work on dynamic applications is a reality. Banishing brittle with self-healing is more than a pipe dream, it’s here. So yes, you can, given the appropriate skill, time, and money, make Selenium do what you need it to. But again, just because you can does not mean to say you should. That said, I am dreaming of my breakfast-making contraption. If you know a dog with the appropriate engineering skill, please get in contact. If you don’t think that’s going to be possible, then please still do get in contact and book a demo.