Reading Time: 2 minutes

It was 8 AM during one of the critical release regression times, our SDET came to office and found that 60% of his tests failed due to changes in UI (element IDs changed, new elements introduced, elements removed etc). It is a suite of about 2000 Tests, can we analyse all of these 1200 failed tests in the next few hours and find the reasons? How easy is it to fix them? Should we really fix them? Can some astrology help?

Then came the idea to build an Application Change Identifier and Application Change Predictor

Application Change Identifier and Predictor


Performance TestingApplication Change Identifier and Predictor

A Page Depot is where the elements across pages in the application are stored in a map with their location parameters like ID, name, xpath, also their accessibility parameters such as visible, enabled etc. Every time theĀ  execution is performed, the Stored Page Depot is compared with the newly generated depot (Objects on the page) and the older one is replaced with new. This helps in identifying the test automation failures due to UI changes, locator changes etc

Application Change Predictor walks through last Several Commits in the SCM and identifies the modules / pages affected. Picks the tests corresponding to these pages and runs the application change identifier.

Stay tuned for our code on GitHub

Want to collaborate with us? Please write to

Skills Needed: Selenium, Core Java, out of box thinking