| To be honest, that likely had little to do with Selenium (although there were fewer options around back then) but more with the expectations around the tests. UI front-end tests are often brittle because people try to test things through them that should have been tested in earlier stages. Either on API level or unit level. Just to give a simple example. Say you have a login screen. It has a username input, password input, login button and finally a div to show any messages. The only things you actually want to test here are: 1. A succes login action
2. A action that leads to a message being shown in the message div.
3. *If* there are multiple categories of messages (error, warning, etc) possibly one of each message. What you don't want to test here are all sorts of login variations that ultimately test input validation (API level) or some other mechanism surrounding password (possibly unit testing). The problem is that often, and certainly the decade earlier you are talking about, is that companies often take their manual regression tests and just throw them into automation. Forgetting that those manual regressions tests are equally brittle but that this is often overlooked due to the way manual tests are done and reported on. Having said all that. Selenium is still a solid option in a java environment. But as others have pointed out, there are other very solid options out there like Playwright.
But these also can be equally as brittle if the tests are not setup properly. |