To add to @Dhiman's excellent answer, and noting that limits mentioned by @log_file was not a problem for me:
- Selenium is W3C standard for browser automation, so it is here to stay.
- For competent programmer, programming (instead of session recording) is not a bug, but a feature.
With competent programming team, you can develop pageobjects and reuse them in extremely flexible ways. We have multiple ways to generate data to feed into our integration testing system:
- one of the paths collect some transaction data from production and replays them in testing system.
- Another use of Selenium is to generate reports for the same datapoints in production and testing, and compare them to detect the differences. Because we replay data, we can analyze detected differences and automate major part of the diff analysis.
- and of course standard regression tests.
So in some sense, some of our tests are data-driven (we can generate data sets for test, instead of endlessly replaying the same tests). Fuzzying, border conditions testing - just generate proper data sets.
Also in our experience, record/replay test are very fragile and sensitive to UI changes. After even a small change, many tests needs to be updated. With pageobject design pattern, such changes are localized and much simpler to manage.
I do not have experience using other competing automation framework (beyond dabbing into our legacy FitNesse a bit). But our company policy is to use open source tools for production whenever possible, because in our experience the response from commercial support is often delayed way into the future, and often forces you to "upgrade treadmill" - solution is "yes, we will fix it in next version of our library", so skipping version upgrades (as we like to do) would not be possible. From our POV such approach is unreliable - they are solving their problem, not ours.
With open source systems, if we do have some problem, usually someone else already solved it, and solution is discoverable by google search and some own development. Or you can always try to solve it yourself or hire an expert on hourly rate (buy time with money), which is not possible with closed systems.
With 2 years of experience in Selenium, I would not consider switching to proprietary test system if I can avoid it.
Yes, cross-browser testing is a problem, and IE is as usually the biggest offender - because MSFTies think that being incompatible with web standards will allow them to hang on the chunk of the market they have. If your IE customers are minority, incompatibilities are MSFT's problem not yours.