Comment activer la réutilisabilité avec les référentiels d’objets en test d’automatisation
En tant que développeur en automatisation, n’éprouvons-nous pas un certain sentiment de satisfaction lorsque l’équipe de tests manuels, ou le client, nous fait part des bénéfices tirés de l’automatisation que nous avons créée ? Pour cela, nous misons sur une suite d’automatisation de haute qualité, non seulement robuste, mais aussi facilement adaptable aux mises à jour requises selon toute évolution des besoins métiers ou techniques. L’entretien doit être aisé—c’est ce que nous ne cessons de nous rappeler. Comment y parvenir ?
Parmi les différentes méthodes permettant d’assurer la qualité d’une suite de tests automatisés, l’une d’elles consiste à garantir la réutilisabilité—pas seulement en réutilisant des étapes de test courantes, mais aussi en réutilisant des objets d’interface utilisateur (UI) fréquents. Dans cet article, je vais expliquer comment exploiter les référentiels d’objets pour améliorer la réutilisabilité via la réutilisation des objets dans un projet d’automatisation de tests UI.
- Qu’est-ce qu’un référentiel d’objets en automatisation des tests ?
- Pourquoi est-ce important ?
- Bonnes pratiques à suivre lors de l’utilisation de référentiels d’objets
- Comment créer un référentiel d’objets (exemples)
Qu’est-ce qu’un référentiel d’objets en automatisation des tests ?
Lorsque vous débutez la conception de la suite d’automatisation des tests, la plupart d’entre nous veillons à ne pas réécrire des blocs de code. Pour cela, nous créons des fonctions réutilisables, mettons les blocs de code réutilisables à disposition dans des bibliothèques. Cependant, avez-vous déjà réutilisé des objets UI courants ? Sinon, laissez-moi vous expliquer comment vous pouvez le faire en utilisant un référentiel d’objets comme base.
Un référentiel d’objets est une collection d’objets UI fréquemment associés ensemble. Cela améliore non seulement la réutilisabilité, mais assure aussi la fiabilité et la gestion des éléments d’interface dans la suite d’automatisation.
Lors de la création des scripts d’automatisation des tests, vous aurez associé des étapes des scripts à chacun de ces objets UI. Par exemple :
- Saisir du texte dans un champ de saisie (UI text box)
- Récupérer le texte d’un objet d’étiquette (Label UI object)
- Cliquez sur l’objet de lien hypertexte … et ainsi de suite.
Maintenant, comment améliorer la réutilisabilité en réutilisant les objets UI sur lesquels vos scripts travaillent ?
Eh bien, si votre outil d’automatisation des tests dispose d’un « référentiel d’objets », c’est simple. Grâce à ce référentiel, vous pourrez rassembler les objets UI et ajouter, supprimer, gérer ou mettre à jour ces objets de manière organisée. Vous pourrez ensuite réutiliser ces objets en les référant depuis vos scripts.
Analysons une situation où vous n’utilisez pas de référentiel d’objets dans votre suite d’automatisation. Dans ce cas, pour chaque script automatisé distinct utilisant le même widget UI, vous ajouteriez plusieurs copies du même objet UI dans chacun des scripts afin d’effectuer des opérations dessus.
Voyons maintenant le cas où l’on utilise un référentiel d’objets. Ici, vous disposez d’un emplacement unique où sont stockés les objets UI. Ainsi, dans chaque script qui doit interagir avec le même objet/widget, il le référence à partir de ce référentiel. Il n’y a donc qu’une seule copie de l’objet UI dans la suite de tests, sur laquelle plusieurs scripts s’appuient. Et c’est là que la réutilisabilité prend tout son sens !
Pourquoi est-ce important ?
Ma première expérience avec un référentiel d’objets remontait à l’utilisation de l’outil IBM Rational Functional Test Automation. Depuis, à chaque fois que j’explore un nouvel outil, je vérifie s’il propose cette fonctionnalité de référentiel d’objets ou non.
La première fois que j’ai employé un référentiel d’objets, c’est lorsque notre équipe automatisait une vaste interface web d’administration comprenant de nombreuses pages. Plus de 100 cas de tests étaient à automatiser. Sans référentiel d’objets, cela aurait été un véritable défi. Nous avons donc analysé la situation et conclu que la suite d’automatisation que nous envisagions était le cas idéal pour utiliser un référentiel d’objets.
Pourquoi ?
1. Chacun des cas de test automatisés comportait plusieurs sous-flux identiques, par conséquent des widgets UI étaient partagés entre eux.
Grâce à ces sous-flux communs, on retrouvait logiquement des objets UI communs dans différents scénarios. Nous ne voulions pas dupliquer en permanence les mêmes objets, nous avons donc opté pour la réutilisation d’objets UI.
Par exemple, un ensemble de cas de tests devait parcourir les mêmes liens du menu de navigation avant de réaliser certaines actions. Nous avons donc prévu un référentiel destiné uniquement à la gestion de ces liens de navigation. Nous avons ainsi pu réemployer ces liens dans un fichier de référentiel d’objets.
2. On nous avait informés que, dans le futur, il pourrait y avoir des évolutions de l’UI—liens hypertextes, étiquettes, etc.
Nous souhaitions donc nous assurer que, le moment venu, la suite d’automatisation serait facilement adaptable aux changements et que l’effort de maintenance serait réduit au minimum.
C’est là que le référentiel d’objets nous a sauvé la mise : inutile de mettre à jour chaque occurrence de l’objet UI ; il suffisait de modifier le seul objet concerné dans le référentiel et les scripts se mettaient automatiquement à jour et s’exécutaient avec l’élément modifié.
3. Nous devions construire une suite d’automatisation de tests de plus de 100 scripts en un mois !
C’est ici qu’un autre avantage de l’utilisation d’un référentiel d’objets (OR) est apparu : en adoptant l’approche de création d’un OR et en évitant à chacun de nous de devoir ajouter les mêmes objets d’interface utilisateur, nous avons gagné du temps. Nous avons construit un OR bien organisé, et tout ce que nous avions à faire était de développer notre code autour des objets que nous avions déjà organisés dans l’OR.
Nous nous sommes concentrés sur l’objectif du cas de test et sur la logique métier des cas de test au lieu de perdre du temps à réinventer la roue en ajoutant les objets pour chaque script de test. Nous avons ainsi économisé du temps et, finalement, livré la suite d’automatisation de tests dans le délai visé d’un mois !
Bonnes Pratiques À Suivre Lors De L’utilisation De Référentiels D’Objets
Maintenant que vous connaissez les situations où un référentiel d’objets d’UI peut aider, ne voulez-vous pas savoir ce qui le rend efficace ?
1. En équipe, définissez un objectif commun de réutilisabilité. Ensemble, comprenez pourquoi cela peut être utile à votre équipe d’automatisation, à l’équipe de tests manuels et, au final, au client.
2. Pendant le développement de la suite d’automatisation des tests, synchronisez-vous en équipe et informez-vous régulièrement sur les objets que vous créez. Mettez en place des règles de regroupement et des conventions de nommage auxquelles vous vous tiendrez tous. Lorsque vous commencez, vous pouvez définir un plan d’organisation et de stockage de chaque fichier OR. Par exemple, les objets du menu de navigation dans un fichier OR, les objets de l’interface de connexion dans un autre, etc. Vous pouvez également choisir des conventions de nommage pour que les objets soient faciles à retrouver.
3. Veillez à nommer les objets UI de façon lisible, facilement trouvable et compréhensible. Les objets UI doivent être nommés de façon à ce que toute personne qui parcourt le référentiel avec l’intention de le mettre à jour puisse retrouver facilement l’objet concerné. Dans l’exemple ci-dessous, je vous montre une telle situation.
Comment Créer Des Référentiels D’Objets (Exemples)
Voyons désormais comment vous pouvez rapidement démarrer avec les référentiels d’objets. Des outils comme UFT, IBM RFT, UiPath Test Automation Suite et Power Automate possèdent des référentiels d’objets intégrés. Alors, qu’attendez-vous ? Croyez-moi, c’est super facile !
Voici un exemple où j’ai créé un OR concernant le site QAL :
Observez l’interface ci-dessus – j’ai regroupé tous les widgets associés aux actions sur la page de connexion car ils sont communs à plusieurs cas de test. Ensuite, j’ai regroupé les liens de navigation. Si nous devions enregistrer ces objets dans un groupe, alors lorsque tous les scripts de test utiliseront forcément ce groupe d’objets de liens UI au début de chaque cas de test, ces objets pourront être réutilisés au lieu d’être ajoutés de nouveau dans le référentiel.
Exemple d’Utilisation Du Référentiel D’Objets Dans UiPath
Voici à quoi ressemble le référentiel d’objets dans l’outil UiPath :
Dans cet exemple de référentiel d’objets, j’ai organisé les objets « Page de connexion » dans un ensemble et les « Liens de navigation principaux » dans un autre. Ainsi, si je dois créer plusieurs scripts de test pour, par exemple, tester la page de connexion, tous les scripts utiliseront les mêmes objets placés dans l’ensemble « Page de connexion ».
Exemple d’Utilisation Du Référentiel D’Objets Dans PowerAutomate
Voici à quoi ressemble le référentiel d’objets dans l’outil PowerAutomate :
Comme je l’ai mentionné plus haut, la clé de la réutilisabilité est aussi de nommer les objets pour qu’ils soient facilement retrouvables plus tard. Observez par exemple l’objet UI « meprmath_quiz ». Contrairement aux autres champs, il est difficile d’identifier facilement à quoi cet objet se rapporte. Ainsi, dans un cas comme ci-dessus, même si lorsque j’ai ajouté l’objet UI « quiz » le champ s’appelait « meprmath_quiz », nous pourrions peut-être le renommer en « login_add » afin qu’il soit simple à localiser lors de l’automatisation et la maintenance de l’OR.
En Résumé
Alors, comment utilisez-vous l’OR dans votre outil d’automatisation préféré ? Nous serions ravis de le savoir.
J’espère que cet article vous a aidé à comprendre comment l’OR aide l’équipe sur le long terme. Nous avons la chance de vivre à une époque où la plupart des outils d’automatisation de tests proposent cette fonctionnalité OR. Par conséquent, il ne vous reste plus qu’à explorer comment elle fonctionne dans votre outil favori !
Vous avez appris quelque chose de nouveau dans cet article ? Si vous souhaitez lire d’autres articles du même type, n’oubliez pas de vous abonner à la Newsletter The QA Lead !
Lectures connexes :
- MEILLEURES PRATIQUES POUR L’AUTOMATISATION DANS LA TRANSFORMATION DIGITALE
- QU’EST-CE QUE ZEPHYR SCALE ?
Liste d’outils associés : LOGICIELS DE TEST DE PERFORMANCE POUR ÉQUIPES QA
À découvrir également :
