I agree with most of the comments here. “Context” is king. I know you mentioned you wanted to do web testing, so some things to consider when choosing a good tool/platform would be-
- What problems are you trying to solve?
- How many technical/non-technical people you have in the team?
- How much time, cost and effort you are willing to spend on picking an automation platform and then building automated tests?
- How much time, cost and effort you may save by having automation?
- How many people are going to be involved in it?
Once you have answered some of the above questions, then you will get a better picture of what you are looking for.
Selenium has been around for a while and is one of the most popular open source testing tools out there. I myself have used Selenium for 8 years and it does have some great features. The reason people are still using Selenium is-
- It is FREE. You do not pay for any of the services
- It is “Technical Friendly” . Anyone who is used to writing code to build things will love Selenium; as what code you write is what gets implemented in automation. So developers and technical testers are more inclined towards using this compared to record/playback tools
- It is Extensible . You are free to add your own wrapper around Selenium to do whatever functionalities you want. This is lacking in most of the codeless testing automation tools
That being said I think it does have its own limitations such as
- Spending majority of your valuable testing time fixing flaky tests
- Unable to make automation progress due to the lack of skilled programmers to write automated tests
- Not finding enough support in the open source community when new libraries and updates break existing tests and you have no idea what to do
- Need of visual validation when a step fails, to visually understand the exact reason for the failure
- Insufficient logging information when your tests fail
- Finding it hard to seamlessly integrate your automated tests within your CI/CD pipeline
- Inability to handle dynamically changing elements on the web page
- No inbuilt functionalities to automate actions that involve multiple tabs, hovers, scroll and other complex user actions
- The need to give explicit and implicit waits manually to make tests more stable
NOTE: Selenium was built by people who care about testing and they actually help to maintain/update it outside their actual jobs. So, we cannot complain if Selenium has problems as people are doing their best to maintain it. In fact, a lot of codeless platforms have some components of Selenium built into it.
To avoid some of the limitations of selenium, people may look into codeless automation platforms. And again, they do have their own advantages and disadvantages just like selenium.
The biggest issue with record and playback tools is, it is not extensible like selenium and you are confined by the features provided by the tool and if you want to do something extra the tool does not provide; your hands are tied. At the same time it does help to get everyone involved in automation including non-technical people who have really good testing and domain knowledge.
I personally work at Testim and have been helping to make our codeless testing platform better to overcome the above limitations. You can read about how we make the platform extensible here - https://blog.testim.io/why-testim/.
I have also personally used MABL, Functionize and they are good in their own ways.
In summary, it all boils down to what you want to do? what kind of application you are testing? and how much you are ready to invest in UI automation?