Une approche simple pour gérer les échecs de l’automatisation des tests

Il était 8 heures du matin pendant l’une des périodes critiques de régression de la version, notre SDET est arrivé au bureau et a constaté que 60 % de ses tests échouaient en raison de changements dans l’interface utilisateur (ID d’éléments modifiés, nouveaux éléments introduits, éléments supprimés, etc.). C’est une suite d’environ 2000 Tests, peut-on analyser l’ensemble de ces 1200 tests ratés dans les prochaines heures et en trouver les raisons ? Est-il facile de les réparer ? Doit-on vraiment les réparer ? Un peu d’astrologie peut-elle aider?

Puis est venue l’idée de créer un identifiant de changement d’application et un prédicteur de changement d’application

Identificateur et prédicteur de changement d’application

Identificateur et prédicteur de changement d’application

Un dépôt de pages est l’endroit où les éléments des pages de l’application sont stockés dans une carte avec leurs paramètres d’emplacement tels que ID, nom, xpath, ainsi que leurs paramètres d’accessibilité tels que visible, activé, etc. Chaque fois que l’exécution est effectuée, le dépôt de la page stockée est comparé au dépôt nouvellement généré (Objets sur la page) et l’ancien est remplacé par le nouveau. Cela aide à identifier les échecs d’automatisation des tests dus aux changements d’interface utilisateur, aux changements de localisateur, etc.

Application Change Predictor parcourt les dernières validations multiples dans le SCM et identifie les modules/pages concernés. Prend les tests correspondant à ces pages et exécute l’identifiant de changement d’application.

Restez à l’écoute de notre code sur GitHub

Vous souhaitez collaborer avec nous ? Veuillez écrire à sales@zucisystems.com

Compétences requises : Selenium, Core Java, pensée originale