In Agile methodologies, UI changes rapidly and its very tough to maintain automated regression suite. Is there any approach, with which we can update it automatically or at least minimize the maintenance efforts.
IMHO, if your UI changes so often that your tests become utterly redundant over a single Sprint - which I am assuming is a 10-15 day period, then the actual issue lies with your UI developers rather than the QA/Testing team. Your UI team should focus on how to minimize the extent of impact of their changes. Completing a project, on time, with good quality, is dependent of the whole team - not just the QA team. If one team is poor in their implementation, then sooner or later, it is going to impact the overall quality of the product delivered.
Nevertheless, changing UI - even if it is not that frequent poses difficulties for testers, particularly, who are trying to write automated e2e tests, or tests in general using tools like Selenium, which rely on the underlying HTML for their implementation. Here are a few practises you can follow to minimize the changes that you do in your codebase -
Use Page Object Model - There are like hundreds of article on the web regarding how POM can be beneficial when it comes to rapidly changing environments. You can follow the POM principles, which would radically reduce the amount of changes that you need to make in your codebase once changes from frontend are done.
Rely on Good Locators - When I say good locators, then I put emphasis on using a lot less of brittle locator - for example absolute xpaths or even Xpaths in general. The good people of SQA community have answered this in a very detailed way here. Implementing these really helps your codebase (I have added these to my framework and it does wonders.
Relying Less on UI for Testing - Don’t just utilize the UI for smoke testing if the UI / Application / Workflows change drastically and very often. Most of the time it is also helpful to test certain functionalities by calling WebServices without any Web-UI
First of all follow the Page Object Model architecture to least the efforts. For reference follow the https://www.guru99.com/page-object-model-pom-page-factory-in-selenium-ultimate-guide.html
Further QA testing companies while automating a test case or scenario prioritize the use the identifiers in order
id > class > name > CSS and then least priority will be
Xpath should not be used as priority because whenever there are changes in the UI
Xpath of the locators always changes.
Also the locators should be stored in variables, So that whenever there are changes in values of locators the locator should be updated only in variable and it can be used in different functions. like e.g.
loginButton = Login; //here we are using id for Login getDriver().findElement(By.id(loginButton)).click();
We should avoid the use of locators directly in functions like
In this case we have to update the value of login button twice, So we should avoid the scenario.
loginButton = Login; getDriver().findElement(By.id(loginButton)).click(); isElementPresent(By.id(loginButton));
In the above example we simply have to update the value of loginButton and it will be reflected and can be used in both the functions.
Even if UI changes, there is no reason to change IDs and names of element which are moved around or CSS styling changes.
And if your GUI designers are making changes like that (renaming existing items), your (QA) manager needs to talk to dev manager.
It is a business decision: such changes will break existing test, and efforts will have to be spent to fix such tests. If business decides such make-work is waste, developers will have to stop making such unnecessary name changes. If business decides it is important for creative freedom of GUI designers: such freedom has a cost. Even if not paid by GUI developers, it is paid by company as a whole, by QA which will be fixing old test instead of creating new ones.
Of course it assumes best practices like naming conventions, Page Object etc.
Have the UI devs run the tests as they make their changes.
You'll need to set up the systems, people and processes so this can be done easily and smoothly. I recommend have QE's (Quality Engineers) on code review for any test changes so that they can advise on writing good tests with Page Objects, etc.