le-blog-b-acceptance.1.jpg

Blog B/Acceptance

Choix d'un automate IHM. Quels outils  pour construire vos scripts ?

Posté par Le Lab B/Acceptance le 21 juin 2019.

Au travers des articles précédents, je vous ai présenté les concepts qu'il faut garder en tête d'une part lorsque l'on compare les fonctionnalités des automates de test, d'autre part lorsque l'on lance une démarche d'automatisation de la non régression. Lors du choix de votre outil d'automatisation, le mode de construction proposé devra également faire l'objet d'une attention particulière.

Mettez un automate, tout aussi puissant qu'il soit, entre les mains de quelqu'un qui ne sait pas l'exploiter ou qui n'y trouve pas d'intérêt et votre démarche sera un échec. Mais comment choisir ? Certains vous vanteront les bienfaits des outils codeless là où d'autres ne jureront que par des outils de scripting dans des langages tels que Java, C# ou Python (et bien d'autres encore). Qui devez-vous écouter ?

Record & Playback : Retour au basique

C'est quoi ? Le record and playback, c'est un peu l'équivalent de l'enregistrement d'une macro sous Excel.

Vous déroulez votre test manuellement pendant que l’automate se charge de capturer :
  • Les éléments IHM avec lesquels vous interagissez.
  • Les actions que vous réalisez.
Avantage
  • Nul besoin d’être expert en automatisation, le record and playback ouvre largement les portes de l’automatisation aux profils fonctionnels.
Inconvénient
  • Cette méthode n’est pas la plus robuste.
  • Maintenir un action word revient à le réenregistrer.
  • Le record and playback ne permettra pas de gérer des contraintes de données ou de gestes complexes (ex: je dois vider un panier dont je ne maîtrise pas le contenu initial en cliquant successivement sur la suppression des produits / je dois paginer les résultats d'une recherche pour identifier le produit correspondant à mon cas fonctionnel)
  • Les scripts ne peuvent être construits et maintenus qu'après livraison de la version à tester.
Quand l'utiliser ?
  • La technique n’est pas votre tasse de thé.
  • Votre application sous test est de bonne qualité.
    J'entends par là d'une part que le comportement de votre application est maîtrisé (pas d'événement intempestif : time-out, pop-up d'alerte) et d'autre part que vos éléments IHM sont clairement identifiables (des éléments IHM clairement identifiés simplifient la lisibilité de vos scripts)
  • Les jeux de données sont maîtrisés (ex.: le produit que vous avez utilisé sera toujours disponible en première position / votre panier sera toujours vide).

 

CodeLess : What you see is what you get

C'est quoi ? Un éditeur vous permet de composer des scripts en vous cachant le code.

Vous disposerez usuellement :
  • D’un outil pour capturer et ranger vos éléments IHM (l’object repository)
  • D’un outil de scripting en glisser déposer proposant par exemple la démarche suivante :
    1. Je choisis un objet
    2. Je le glisse au sein de mon script
    3. Je lui affecte un geste
  • D’un outil pour organiser vos scénarios de test
Avantage
  • Cette méthode permet d’ouvrir des tests plus complexes à une population non technique
  • Les outils CodeLess mettent usuellement en place des mécanismes permettant de réduire les besoins de maintenance.
  • Le scripting et la maintenance peuvent être initiés avant mise à disposition de la version sous test.
Inconvénient
  • Le succès de l’automate dépend très fortement de la qualité du système testé.
    Dans une solution entièrement CodeLess, vous n’aurez pas le luxe de pouvoir scripter une solution de contournement dans le cas d’une automatisation difficile.
Quand l'utiliser ?
  • Vous n’avez qu’une connaissance superficielle du développement.
  • Votre application sous test est de bonne qualité.

 

Scripting : Avec des vrais morceaux de code dedans

C'est quoi ? A vous lignes de code et fichiers properties… accompagné de votre plus fidèle environnement de développement (Eclipse, IntelliJ, Visual Studio, …), vous développerez vos scénarios automatisés entièrement à la main.

Plus sérieusement, Il s’agit ici d’écrire/intégrer le code permettant tout ou partie des fonctionnalités suivantes :
  • La composition de vos scénarios
  • L’implémentation de vos ActionWords
  • La description de vos écrans au travers d’un PageObject par exemple
  • La gestion des données de test au travers de DataSource et DataProvider
Avantage
  • Une fois que vous aurez compris l’ensemble des mécanismes de votre automate, il sera possible de se sortir des situations les plus épineuses (écrans complexes, étapes de contrôles complexe).
  • Vous disposerez également de l’ensemble des outils de votre langage de développement.
    Ceci vous permettra rapidement d’intégrer dans vos scénarios IHM, des étapes techniques pour lesquelles un passage par l’écran aurait été complexe (lancement d’un batch par une connexion Putty, contrôle en base de données, appel d’un web service, …).
Inconvénient
  • Cette méthode demande de réelles compétences en développement. L’exploitabilité et la maintenabilité de votre automate en dépendent. Une architecture bien pensée vous fera gagner un temps fou. Une architecture approximative vous fera perdre davantage de temps qu’une exécution de campagne manuelle.
  • Le ticket d'entrée (en terme d'effort humain) est un peu plus élevée que pour un les autres modes.
Quand l'utiliser ?
  • Le futur automaticien dispose de connaissances techniques.
  • Vous avez la nécessité d'automatiser alors que vos applications sous test :
    • Ne sont pas matures
    • S’appuient sur des technologies anciennes
    • Ont été développées sans suivre des bonnes pratiques IHM

 

Quelle outil/approche choisir ?

Chaque outil d’automatisation applique une approche spécifique s’appuyant sur une combinaison de ces 3 méthodes. Dans un automate tel que Ranorex, vous aurez notamment accès à ces 3 modes. Ce qui compte est alors de savoir comment ces approches cohabitent dans l'outil. Faire le choix de scripter une étape m'oblige-t-il à scripter l'ensemble de mon Action Word ou pire encore l'ensemble de mon référentiel ? Ne serais-je pas trop limité par un mode Record and Playback ?

Pour choisir un outil d’automatisation, il faut connaitre, avant tout, votre future organisation :

  • Maîtriser la testabilité des applications testées.
  • Connaitre les personnes qui concevront les scénarios.
  • Connaitre les personnes qui implémenteront les scripts automatisés.
  • Connaitre les personnes qui exploiteront vos tests (préparation, lancement, analyse, …)

Plus vous êtes dans un contexte de qualité, plus il est simple de se diriger vers une solution Record and Playback ou CodeLess.
A l’inverse, plus votre contexte est incertain, plus il faudra descendre vers une solution codée. Votre automate réclamera alors un plus haut niveau d’expertise.

Sachez également que vos méthodes de travail évolueront avec le temps. Il est probable que vous débutiez votre parcours d'automaticien, par la création de scénario en Record and Playback. Ce faisant rechercherez comment améliorer la pérennité de vos scénarios et glisserez peu à peu vers le mode Codeless. Ceci jusqu'au jour où vous vous direz que votre enregistrement initial n'apporte que peu de valeur ajoutée vu le contenu de votre scénario abouti. Avec un niveau de maîtrise accru, il est fort probable que vous ayez envie de faire faire encore plus de choses à votre automate et développerez alors vos premières fonctions codées "à la main". Dans ce sens, il me semble important de ne pas se fermer trop de routes lorsque l'on choisit sa solution d'automatisation. 

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