Automatisation des tests logiciels : analyse des résultats et découverte des régressions

Après la création des scénarios de tests et l’exécution de ces derniers (lire l’article dédié ici), il convient d’analyser les résultats obtenus, d’identifier les défauts et de remonter aux causes racines des dysfonctionnements. Mais pour cela, il faut analyser les résultats en mettant en place un processus de restitution.

Une sous-estimation du temps, du coût et de l’effort :

• La commande est validée : le résultat obtenu est identique à celui attendu.
  • Exemple : 
    • Attendu : clic sur le bouton “Se connecter” et affiche la page id=espaceclient
    • Obtenu : clic sur le bouton “Se connecter” et affiche la page id=espaceclient
• La commande est en défaut : le résultat obtenu est différent de celui attendu
  • Exemple :
    • Attendu : clic sur le bouton “Se connecter” et affiche la page id=espaceclient
    • Obtenu : clic sur le bouton “Se connecter” et affiche la page id=erreurlogin

Exemple d’un scénario avec un défaut depuis l’outil d’automatisation de tests fonctionnels CloudNetCare.

En cas de défaut, il convient de mettre en place un processus d’analyse des régressions pour fiabiliser les cas avérés et fournir un maximum d’informations aux équipes de développements. C’est une étape incontournable pour gagner du temps et éviter les allers et retours entre les équipes avec pour conséquence le retard de la correction du dysfonctionnement.

Il faut commencer par analyser le type de défaut car ce n’est pas nécessairement un dysfonctionnement :

• Si l’action dépend d’un service tiers c’est peut-être ce dernier qui fait défaut. Pour lever cette hypothèse il est pertinent que la commande soit exécutée une deuxième fois pour valider que cette dernière n’était pas dûe à une indisponibilité temporaire. Dans notre exemple ci-dessus le module de connexion peut faire appel à un web services.

• Le jeu de données utilisé n’a pas peut-être pas été incrémenté ou n’est plus à jour. Dans notre exemple, le mot de passe a pu être modifié dans la base de données.

• Etc.

Dans notre exemple, au premier abord le défaut de l’étape 7 pouvait apparaître comme étant un dysfonctionnement de l’application. Alors que ce dernier peut tout aussi bien être lié à une indisponibilité d’un web services. Une mauvaise analyse et une remontée du défaut trop rapide aux équipes de développement pourrait, à terme, créer un climat de défiance quant à la fiabilité des informations de l’équipe QA. À crier au loup trop souvent …

Plus l’outil d’automatisation vous permettra de remonter des informations sur l’erreur et plus vous gagnerez du temps lors de l’analyse. Une capture d’écran entre la page attendue et la page obtenue s’avère indispensable dans le processus d’identification.

Si et seulement si le défaut est avéré comme étant un dysfonctionnement il conviendra alors de solliciter les équipes de développement en fournissant le maximum d’informations possibles.

Par la suite il faudra que tous les résultats soient historisés pour suivre l’évolution de la couverture au fil des itérations. Les résultats peuvent être présentés dans des tableaux de bord dédiés ou remontés dans des outils de consolidation via des API.

Pour conclure.

Dans trop de cas nous rencontrons des équipes qui se retrouvent débordées lors de l’analyse et le traitement des défauts car toutes les ressources ont été mobilisées pour la mise en place de tests automatisés sans trop se préoccuper de la partie exploitation des résultats.

Il n’y a pas de secrets, c’est en suivant ce type de processus à la découverte d’un défaut que vous parviendrez à améliorer considérablement la qualité de vos livrables et par là même, l’expérience utilisateur.