Why is test automation often getting lost in maintenance?
Test automators tend to get lost in maintenance. Automated tests are not a dream tool, that you can run and then it tells you exactly how many errors you have in your application and where they are. Yes, it will find errors, but it will have a lot more fails that are not due to errors.
Automated tests are very fragile creatures. They must interact with all the elements the user interacts with, but if any one of these elements is altered, they will not find them anymore. How can this be? Let us look at a simple example. If we have a button to continue after having selected a payment method, it might have the following html code associated:
Since there might be many buttons on the page, the automated tests will be programed to look for a button with the class “continue”. But if now this class changes, we have this:
The automated test will not find the button and report that there was a button missing. The result will be a failed test. This of course will be a false result from a functional point of view since the button is there. The test then needs maintenance to adapt it to the altered button.
Oftentimes the increased need of maintenance is due to a lack of synchronization between automators and developers. Automators may not be informed about the areas of the application that have changed. And developers of course have no idea on which elements test automators rely on to connect their tests to the website. In particular, when there is a lot of change in design, automated tests are bound to suffer from this, because they often come along with a lot of such minor changes.
Automated tests love long boring forms that they can fill in so rapidly that your eyes cannot follow. If you do not alter the fields, the tests will run forever. Furthermore, one additional problem for automated tests are jungles of popup windows, because they cannot interact with elements that are behind these windows.
As a user we can just click them away when they popup. But an automated test has to wait for the window to popup, even if it is not yet there, then close it and only then it can start interacting with the elements on the page. You can imagine, that this is especially difficult when these windows are not mandatory and may or may not open up.