Dis tonton… comment on script avec un automate de tests et si tu pouvais aussi me donner quelques bonnes pratiques steuplé ?

Hum… et tu ne veux pas non plus 100 euros et un Mars ? Bref, je te sens piaffer d’impatience alors écoute donc…

Je vais tenter de vous exposer comment les automates de tests fonctionnent. Je vais parler des QuickTests Pro (QTP) et autre Sélénium. Des automates utilisés pour les tests fonctionnels, les scénarios de tests utilisateurs, etc.

Il y a deux façons de scripter dans QTP, il y a la bonne et… la bonne !

Je m’explique car vous pourriez penser que je ne veuille faire qu’un rapide et stérile clin d’œil au sketch des Inconnus (à l’attention de nos amis anglophone : Inconnus = groupe de comique français des années 90).

Mais avant de passer en revue les façons de scripter demandons nous à quoi peuvent servir ces fameux automates qui pourraient être la solution miracle aux tests (ou pas…).

Théorie des automates de tests :

Sur un site Web (par exemple) QTP enregistre vos actions (enregistrement du mouvement de la souris, des clics de souris, etc.) et les rejoue à volonté. Vous pourrez ainsi exécuter à l’infini les scénarios de tests tout les soirs et, au matin, après votre café, compulser dans la tranquillité les rapports d’exécution.

Cette définition est un mythe urbain répandu par les éditeurs il y a quelques années lorsque les automates de tests étaient peu connus des clients. Depuis et jusqu’à ce jour, hélas, c’est toujours ce que pensent la plupart des clients…

Autres grands principes des automates de tests :

• Les automates de tests fonctionnent par reconnaissance des objets des IHM (boutons, listes déroulantes, etc.) qu’il stocke dans un répertoire nommé parfois « repository »
• En mode enregistrement, ils capturent les interactions réalisées sur des objets nécessaires lors du déroulement du scénario de test. Il génère un script en VB (pour QTP)
• En mode exécution, ils rejouent le scénario de test à partir du script

Les automates de tests dans la vraie vie :

La seule partie vraie dans la définition théorique est « QTP enregistre vos actions et les rejoue à volonté » !

Le reste n’est possible que chez très peu de client ayant un niveau de maturité important dans l’automatisation des tests. Bref, il y a deux manières de scripter :

Le scripting par enregistrement et reworking :
– Le testeur dispose des IHM et scripte directement
– Il lance le script, relève les erreurs et les corrige
– Une fois son script terminée il doit le faire valider par un autre testeur et ainsi procéder à un cross-checking (notion très importante pour finaliser les scripts)

Le scripting en mode « programmation descriptive » et reworking :
– Le testeur ne dispose pas des IHM et doit donc travailler à partir de spécifications techniques et fonctionnelles. Mais cela est très rare chez les clients. De plus cela impliquerai que les spécifications sont déjà exhaustives, validées et stables… (il est bon de rire parfois ;- )
– Il lance le script, relève les erreurs et les corrige
– Cross-checking

Points importants à prendre en compte :
Principe : On automatise que sur une application STABLE et MATURE ! Sinon, c’est de la perte de temps et de l’onanisme pour Mammouth !
– Principe : 100% des tests manuels ne pas automatisable :

• Il faut savoir prioriser, faire des choix intelligents, utilisation de la loi de Paretto
• Étudier l’intérêt d’automatiser, etc.

– Principe : mener une étude de faisabilité pour déterminer l’intérêt d’automatiser les tests et la faisabilité technique (voir article sur le sujet)
– Retour sur investissement : des campagnes de tests automatisées ne sont rentables qu’à partir de trois, voir quatre itérations de campagne de tests automatiques (à partir d’une courbe de ROI sur trois ans)
– Création des scripts :

• la charge de création des scripts est plus importante que la création des tests manuels
• la difficulté n’est pas dans la capture du script mais dans le choix du critère et du moyen de contrôle du résultat attendu
• il faut mettre des points de synchronisation ou d’attente entre deux actions pour éviter les times out sur l’apparition de résultat attendu
• bonne pratique pour un scénario isolé (meilleure robustesse du scénario = se remettre dans les mêmes conditions que lors de l’enregistrement du script) :

– Préparation des environnements et application
– Génération des JDDT
– Tests de l’application
– Nettoyage des environnements et application

– Jeux De Données de Tests (JDDT) :

• penser à générer les JDDT par l’automate avant l’exécution des scénarios

– Exécution des scripts : la charge d’exécution automatique est moins importante qu’une exécution manuelle
– Maintenance des scripts: la bonne méthodologie et les bonnes pratiques sont à appliquer avant le début de l’automatisation afin de minimiser les charges de maintenance des scripts (normes pour l’organisation, le nommage, la gestion des versions des scripts, etc.).
– Maintenance des scripts: il faut maintenir une compétence d’automatisation pour réaliser les adaptations, évolution des scripts en cas d’évolution de l’application

Je finirai en vous demandant de coupler TOUJOURS et autant que possible votre automate avec votre référentiel de tests ! Ce qui permettra, entre autre, de :
– Stocker la description des scénarios à automatiser
– Stocker les scripts QTP dans QC et les repository associés
– Planifier l’exécution des campagnes de tests automatiques
– Stocker les résultats des campagnes de tests

Dis tonton… comment faire une étude de faisabilité avant d’automatiser mes tests ?

Principe : mener une étude de faisabilité pour déterminer l’intérêt d’automatiser les tests et la faisabilité technique. Ci-dessous le sommaire type d’une étude, avec quelques indications pour vous aider à remplir ce document.

1- En tout premier lieu il faut valider les aspects techniques de l’automatisation : vérifier que l’automate peut se prêter d’un point de vue technique à l’automatisation de l’application (sur un échantillon de scénarios du lot à automatiser)

• Utiliser les documents de pré-requis des automates

2- Prononcer le GO / NOGO

3- Procéder au Prototypage :

– Identifier des scénarios représentatifs en utilisant des scénarios existant manuels :

• Scénario de complexité « Simple
• Scénario de complexité « Moyenne »
• Scénario de complexité « Complexe »

– Mise en place des scénarios dans Quality_Center_TESTLINK_Salome et QuickTests Pro_SELENIUM :

• Automatisation des scénarios (exemple de critères de sélections des scénarios) :
• Périmètre : automatiser sur des fonctions stables (test de non-régression et pas de tests automatique sur les évolutions)
• Fréquence : automatiser les tests sur des fonctions à tester régulièrement
• Criticité : automatiser les fonctions critiques
• Estimer la durée de l’automatisation pour chaque scénario
• Estimer l’exécution manuelle des scénarios (pour comparer les charges)
• Estimer le coût de maintenance des scénarios en cas de montée de version

– Dresser les prémices du ROI :

– Identifier les « Best Practices » à implémenter

• Librairie de fonctions de l’application, fonctions VB réutilisables, gestion des objets, etc.
• Se reporter à l’article sur comment automatiser et les bonnes pratiques
  

– Identifier le mode de gestion des jeux de données

– Faire des préconisations sur la gestion des versions de scripts.

Ci-dessous un petit exemple d’un rapport de faisabilité.

Sommaire du document :

• Objectifs de l’étude

Client_xxx et votre_société on convenu de mener une étude de faisabilité afin de déterminer si une automatisation des campagnes de tests est possible.

Ce qui pourrait permettre d’obtenir des gains de temps conséquent. Ainsi qu’une réutilisabilité par des tiers autre que les équipes votre_société.

L’objectif de cette étude est donc de savoir :

– Quels sont les différents modules / parties automatisables ?

– Avec quels moyens (logiciels, outils) automatiser ces tests ?

– Les gains obtenus sont-ils significatifs ?

• Comment avons-nous procédé ?

Un premier choix a tout d’abord porté sur l’automate (QuickTests Pro_SELENIUM) au vue des contraintes et besoins de Client_xxx.

Ensuite, à partir des scénarios présents dans (Quality_Center_TESTLINK_Salome) nous avons sélectionné quelques tests semblant significatifs.

Puis nous les avons « Enregistré et scripté » à l’aide de l’automate.

Pour illustrer le plus clairement possible les explications : la vidéo ci après montre un exemple concret d’automatisation de test pour l’application AAA, avec l’automate yyyy (nom de la fonctionnalité).

L’automate teste automatiquement :

• 1. Pas 1
  2. Pas n

Joindre la vidéo de l’action de l’automate (outils existant sur Internet et gratuit).

Il est important de prendre un exemple concret sinon l’impact auprès du client en sera amoindri et moins percutant.

• Résultats de l’étude

L’étude de faisabilité a montrée que :

– La plupart des applications sont compatibles avec l’outil d’automatisation xxx. Cette compatibilité a été vérifiée grâce au document « ddd », fourni en annexe.

– Une grande partie des scénarios sont automatisables par Selenium :

· Le module « mmm1 », qui consiste à vérifier le bon fonctionnement de xxx

· Le module « mmm2 »

Les parties non automatisables concernent les échanges de flux entre les différents modules :

· Batchs

· Echange (problème de détection des objets par xxx), etc.