Hey all!
Wanted to understand what’s the best way to go about automating Web testing.
Do you see value in paid codeless automation tools like MABL, Eggplant, Testim etc? Or is Selenium good enough?
Have you used any of these paid tools? Which one is the best?
Well, I haven’t personally used any of them but I’m guessing they offer a layer of abstraction over selenium, which I’m sure they use in the background.
Basically, if your testers don’t code, it might be an useful resource. If they do, there are also open source frameworks like webdriver.io so you don’t need to set one up from zero.
Hello @adityasg13 and Welcome!
I am also considering paid codeless automation tools. In my context, these tools offer a method to have testers start testing sooner, and I would not have the overhead of maintaining automation that I build.
If I were to build a similar solution, I may not have a product ready in time to support the project, and the maintenance would distract me from exploring other opportunities to help
testers and testing.
I’m also interested to hear experiences with these tools.
Joe
I wonder if you would still have the same levels of flexibility? Or at least, enough flexibility that you won’t feel like you need multiple paid suites to achieve what you want.
I do appreciate how much time it takes to maintain selenium scripts though. You can easily fall behind if you have other responsibilities.
Great question, @froberts!
In my opinion, it depends on the application under test.
If the application is one built and maintained by an organization (such as a website), more flexibility may be required. I assume testers have access to all parts of the application. In that case, they can decide the types of testing and automation to apply. I might follow the testing pyramid an have lots of unit tests that explore business behavior.
Moving up the pyramid, some manual or automated tests can explore the UI as well as security, configuration, and connectivity. If the UI is complex, codeless automation products would make less sense to me.
If the application is provided by a vendor (as in my case), I may not need much flexibility. In this case, no one has access to the code of the application. The application has defined workflows that multiple clients use; we have only to configure the application for our specific use.
I would welcome a codeless automation product that allows our testing team to start “testing” immediately. There is not behavior to evaluate (behavior is already tested by the vendor) rather we need to confirm the configurations. Hopefully, those configurations exhibit some evidence through the UI which testers can confirm.
I’m at the start of this journey and today, I believe I will use a combination of codeless automation and other techniques for evaluation in my context.
The more I wrote about this, the more dimensions I started to consider (a good thing!). I hope this provides a peek into how I’m viewing this build vs buy decision.
Joe
Hi @adityasg13,
Firstly, welcome to the Club!
There are no best tools, just the right tool for you and your team. @devtotest has touched on this a bit regarding the context of your product will contribute to which tools to use (although I would raise caution about the testing pyramid - a conversation for another post perhaps @devtotest?).
To identify your tooling you need to look at the testability of your application. How it’s built, what technologies it uses, where it is deployed, etc. all make a difference to the tools you can use. For example if you have well-formed Web APIs, perhaps look at some HTTP testing tools. You can also look at your teams context as well. Automation is a team ownership and not an individuals, so who has experience of automation on your team? What languages do they know? Do you work in a team where individuals are willing to share or pair on problems? All of these questions and more will have an effect as well.
So spend a little time learning more about your context. You may find opportunities you wouldn’t have found if you dive straight into the tools.
In regards to the whole paid vs. open source thing ask yourself. How much is it going to cost me and my team to learn and implement open source tool X? Or how much is it going to cost to hire someone who has the skills we require? I’m not suggesting that money is more important than spending time learning new tools and approaches. But if you see that the cost of a license for a paid tool that is designed to have an easy learning curve and has professional support is less than the cost to your team of going it alone. Then perhaps a paid tool is the right thing for you. You can still use professional tools and learn other open source tools on the side.
Remember, your project and product context will give you the answers you need. Not the features or pricing of a tool.