A Simple Approach To Handle Test Automation Failures
An INFJ personality wielding brevity in speech and writing.
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
Application 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 sales@zucisystems.com
Skills Needed: Selenium, Core Java, out of box thinking
Looking to improve your test automation coverage? Take a look at Zuci’s test automation services and see how you can leverage Zuci for your business needs.
Related Posts