One of the greatest nightmares test engineers experience with Selenium is test maintenance. A small change in the user interface can break tests. Even worse, the failure can happen earlier than reported. This leaves the tester investigating where the break happened, then investing more time rewriting fixes to simple UI changes.
For example, if a tester writes a Selenium script to test an e-commerce store and set an ID to the ‘Add to cart’ button, it can present issues later. If the application changes or there are multiple Add to cart buttons on the page it can move along with testing yet fail later as the wrong button was selected. Pro tip: we encourage you to avoid using IDs. However, use selectors that have a specific meaning.
As mentioned previously, the WebDriver tool is considered the standard choice. It is not a codeless solution. Engineers must be familiar with coding to use it for writing scripts. Therefore the barrier for entry is not geared at non-engineers. Their alternative is the IDE tool, however, this is dismissed by the engineering group because you cannot interject code when applicable.
Selenium also suffers from a lack of built-in image comparison and reporting. Although one can add them with third-party add-ons, it would be great if these components were apart of the core software.
If the grandfather of all automated testing tools lack key features, where does this leave us?