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 (ici aussi). 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 jeux 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.

Publié par

Une réponse sur « Automatisation des tests logiciels : analyse des résultats et découverte des régressions. »

  1. Super article, et tellement vrai !
    Cette problématique a été la base de la création d’ARA (Agile Regression Analyzer), outil maintenant open-source, développé par Decathlon, et présenté lors de la JFTL 2019.
    https://github.com/decathlon/ara
    Les entrants pour cet outil (pour l’instant) : des résultats de tests d’APIs Rest (via Postman / Newman) pour les tests d’intégration, et des résultats de tests Cucumber / Selenium pour les tests systèmes ou les tests d’acceptation.
    L’outil peut aussi être connecté à RTC ou Github (pour lien des problèmes vers vos defects).
    A vous, contributeurs devs, pour avoir d’autres outils liés, comme Jira, Mantis et autres !

    J'aime

Répondre

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l'aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s