le-blog-b-acceptance.1.jpg

Blog B/Acceptance

Choix d'un automate de test IHM. Comment se lancer ?

Posté par Le Lab B/Acceptance le 24 mai 2019.

Bien qu'extrêmement tentante, l'automatisation des tests ne se solde pas toujours par un succès... Pour poursuivre mon précédent article, je vous propose donc aujourd'hui de lister quelques éléments qui pourraient faire échouer votre démarche d'automatisation. Vous voulez éviter les pièges :  Suivez le guide !

Les scénarios de test

Vous pensiez mettre en place une règle de "un pour un" entre votre plan de test manuel et votre futur référentiel automatisé ? Ce n'est vraiment pas la meilleure idée. Vos tests ont été pensés pour des humains qui analyseront leurs résultats au fil de l'exécution, et prendront les initiatives nécessaires pour poursuivre leur test. Un automate ne prendra pas d'initiative ! Pour lui chaque grain de sable doit avoir été prévu,

Pour ma part, face à un plan de test existant, je préfère revenir à la couverture de test cible. Quelles exigences cherchions-nous à couvrir lorsque nous avons rédigé ce plan de test ? Quels scénarios automatisables me permettront une couverture similaire ?

Lors de la conception de mes scénarios automatiques, je privilégie les principes suivants :

  • Un scénario doit avoir le moins de raisons possibles d'échouer. Il ne doit donc pas être trop long et il doit effectuer des contrôles localisés.
    Plus un scénario est long et plus il fait de contrôle, plus il a de chance d'être en échec.
    Dès lors, il y a deux conséquences :
    • Le temps passer à analyser les traces d'exécution sera d'autant plus long que les contrôles sont diversifiés.
    • On se lasse rapidement d'une machine qui dit sans cesse KO.
  • Les scénarios doivent être autonomes. L'exécution d'un scénario ne doit pas reposer sur l'exécution préalable d'un autre, notamment lorsqu'il s'agit de construire un jeu de données.

Les applications sous test

Avant tout lancement d'une démarche d'automatisation, il est primordial d'évaluer l'automatisabilité de vos applications. Même dans le cas d'une application web, qui constitue l'un des domaines les plus propices à l'automatisation, il n'est pas dit que la tâche soit aisée.

Les points à vérifier :

  • Les éléments de vos IHM sont-ils identifiables ?
  • Le modes d'identifications sont-ils pérennes ? Survivront-ils aux futurs déploiements en recette ?
  • Les gestes sont-ils tous automatisables ?
  • Les informations à contrôlées sont-elles rapidement accessibles ?

Les données de test

Comment vos testeurs déroulent-ils leurs tests actuellement ? Ils n'ont probablement pas constitué et communiqué un book de données. Ceci ne pourra pas s'appliquer pour votre automate. Pour lui, la stratégie de création, d'utilisation et de contrôle de la donnée doit être complètement limpide et prédictible.

En phase de stratégie, il faudra lister l'ensemble des objets de données impactant votre automate.
Pour chacun, on identifiera :

  • Le catalogue des cas fonctionnels (appelés aussi données logique) nécessaires.
  • Le cycle de vie de ces données (Création, Rafraîchissement, "Grillabilité", Péremption)
  • Les moyens de contrôle associés à ces données (Bases, services, applicatifs)
  • Le périmètre de données réservé à l'automate = La NO GO ZONE (Un automate a besoin de données qui lui soient dédiées, sur lesquelles on ait assuré l'absence modification imprévue. Faute de quoi, les contrôles seront incohérents.)

L'environnement de test

Votre environnement de recette n'est pas le plus performant ? Vos testeurs ont l'habitude des temps d'attente et de devoir parfois relancer leurs actions pour obtenir les résultats attendus. Ce point, qui dérange déjà un grand nombre de testeurs, a un impact fort sur l'automatisation de vos tests.
La robustesse est le talon d'Achille des automates IHM. Les conséquences majeures d'un environnement lent et/ou instable sont les suivantes :

  • Vous serez obligé de gérer finement la temporisation dans vos scénarios avec pour effet un allongement des délais d'exécution.
  • Les incidents de plateforme seront considérés comme des KO. Les résultats de vos exécutions nocturnes seront donc peu fiables, ne vous permettant pas ainsi de fournir des résultats rapides et fréquents. 
  • Les incidents sont habituellement souvent plus difficiles à diagnostiquer que les échecs sur des points de validation prévus. L'analyse de vos rapports sera donc plus complexe et donc plus coûteuse.

Comme tous les testeurs (et peut être même un peu plus), un automate préférera s'attaquer à un environnement stable et performant.

Votre organisation

Vous avez trop de régressions ? Vous voulez donc rapidement disposer de votre automate. Vous pensiez mettre en place un projet d'automatisation dédié avec une task force qui réalisera les tests de manière complètement autonome. Vous parviendrez ainsi a obtenir rapidement un premier lot de scénarios automatisés.
Parfait ! Mais si votre cellule d'automatisation n'est pas en lien étroit avec le release management et le product management, ce premier lot sera rapidement obsolète :

  • Vos automaticiens corrigeront leurs scénarios en réaction aux échecs constatés.
  • Ceci induira un délai d'obtention des résultats de test plus long.
  • Les personnes testant manuellement votre application verront les défauts majeurs avant votre automate.
  • Elles le feront savoir !

Pour éviter cela, considérez l'automatisation comme une démarche intégrée au processus de delivery.

  • En phase de conception :
    • L'automaticien participe à l'élaboration du planning.
    • Il identifie les impacts des futurs développements sur l'automate.
    • Il exprime ses propres besoins vis-à-vis du développement dans l'objectif d'améliorer ses tests : adaptation d'écrans, mise en place de web services, ...
  • En phase de développement :
    • Il met à disposition ses tests
    • Il supporte l'équipe dans le cadre de leur utilisation.

 

Fort d'une base solide, vous aurez davantage de latitude au moment de choisir un outil d'automatisation.
Notre prochain article s'attardera sur les modes de scripting au sein des automates.

Catégories : automatisation, outils de test

Bienvenue sur le blog de B/Acceptance, spécialiste du test/qualité logicielle en France.

Son objectif :

  • Diffuser et faire découvrir des bonnes pratiques et des outils du test fonctionnel, test automatisé et test de performance
  • Identifier les tendances : automatisation des tests, Intégration continue, Agile Testing, etc
  • Echanger autour du test digital : Web desktop, Web mobile, App

Lire nos articles

Inscrivez-vous au blog