Automatiser ou ne pas automatiser? Telle est la question.

Cet article est fortement inspiré de celui-ci, que j’ai lu grâce au groupe Ministry Of Testing un groupe que je recommande fortement à tous les testeurs qui ne sont pas allergiques à la langue de Shakespeare. Pour ces mêmes personnes voici ma version (librement interprétée, ce n’est pas une traduction) mais dans la langue de Molière.

L’idée est de déterminer s’il est intéressant ou non d’automatiser et si oui, quels sont les problèmes fréquemment rencontrés avec l’automatisation.

Pour rappel j’avais déjà fait un article sur l’intérêt ou non d’automatiser. Ce dernier va étudier le sujet plus en profondeur.

Les conditions pour que l’automatisation soit intéressante :

1.      La présence de test de régression à exécuter régulièrement.

a. Comme déjà expliqué dans mon article Tests autos vs Tests manuels le nombre d’exécutions est primordial afin d’avoir un retour sur investissement intéressant avec l’automatisation.

2.      Avoir une interface utilisateur stable et de nombreux changements de code

a. Je parle ici de tests fonctionnels et donc de l’utilisation de l’interface utilisateur. Si cette dernière évolue tous les cas sont à mettre à jour.

3.      Vouloir implémenter une plateforme d’intégration et/ou de déploiement continu.

a. Dans ce cas on a besoin d’une exécution rapide et à n’importe quel moment des tests

Si au moins une de ces conditions est remplie alors l’automatisation des tests peut être intéressante et est à envisager.

Ici tout est question de Retour sur investissement. Il est intéressant d’automatiser si on a de nombreuses exécutions des tests avant de devoir les mettre à jour. Il est également intéressant d’avoir des tests automatisés si l’on veut d’un point de vue stratégique avoir des tests dont l’exécution est rapide.

Pour que le projet ou l’équipe soit prêt pour l’automatisation il faut s’assurer que :

1.      Les tests manuels sont facilement automatisable

a. Bien écrit : 1 Action => 1 Résultat

b. Stable, ne demandant pas de petits changements ou de recherches spécifiques

2.      Il y a assez de budget pour l’investissement dans les tests automatisés

a. Le coût d’implémentation des tests automatisés est important. Le retour sur investissement n’arrive qu’après

3.      Les membres de l’équipe sont assez techniques pour automatiser les tests

a. Le KDT peut servir dans le cas de testeur fonctionnels mais dans ce cas il faudra peut-être plus de budget pour l’implémentation des outils d’automatisation.

4.      Il y a un budget suffisant pour former l’équipe à l’utilisation des outils d’automatisation

5.      Il y a assez de temps pour implémenter les tests automatisés

a. En effet les tests automatisés font gagner beaucoup de temps sur le temps d’exécution mais nécessite également du temps afin de les écrire.

b. Il faut également du temps pour former les membres de l’équipe sur les nouveaux outils ?

6.      Il y a assez de temps pour maintenir les tests automatisés

a. Maintenir les tests automatisés est beaucoup plus coûteux en temps et en argent que maintenir des tests manuels. Des tests non maintenus sont des tests inutiles (voir dangereux car n’assure plus de couverture et laisse l’équipe dans le flou par rapport à la fonctionnalité que le test couvre)

7.      L’équipe veut automatiser des tests

a. Il est plus facile de passer à l’automatisation si cela est une envie ou demande de l’équipe

8.      Le projet n’est pas en fin de vie

a. Dans le cas d’un projet en fin de vie et qui ne sera pas maintenu, l’investissement dans les tests automatisés n’est pas intéressant.

Problèmes fréquents avec l’automatisation :

1.      Une mauvaise évaluation du coût d’implémentation des tests automatisés.

a. Écrire des cas de tests automatisés prend du temps, surtout si les outils et/ou langages utilisés sont nouveaux pour les membres de l’équipe.

2.      Un outil non adapté

a. Commencer l’automatisation des tests sur un outil non adapté est souvent synonyme de perte de temps et de fiabilité. Un outil non adapté peut poser problème au niveau de la performance, de sa stabilité ou des possibilités qu’il offre.

b. Il est fréquent de devoir « jeter » les tests écrits sur un outil peu adapté pour devoir les réécrire sur un nouvel outil. Les KDT peut éviter ce genre de mésaventure.

3.      Des membres de l’équipe pas assez bien formés

a. Des tests automatisés doivent être fiable, il faut toujours faire attention à ce que l’on recherche.

 i. Par exemple : si j’arrive sur un page et veut vérifier que mon trajet se fait bien en Bus, et que je recherche dans la page le mot « Bus », ce test peut être non valide si dans la même page le mot « Business » (comme classe Business) est présent. En effet dans ce cas « Bus » sera toujours présent.

ii. Un test en succès alors qu’il devrait être en échec est un cauchemar, en effet on analyse les cas en échec, pas les cas en succès !

b. Certains membres de l’équipe ne sont peut-être pas assez techniques et ont besoin d’une remise à niveau

 i. Ici le KDT peut également aider mais a un coût

c. Certains membres de l’équipe peuvent avoir besoin de formation sur le langage de programmation qui sera utilisé pour l’automatisation.

4.      Vouloir 100% de tests automatisés

a. C’est une erreur fréquente, certains tests sont peu stables ou très dur (donc coûteux) à automatiser.

b. D’autres sont rarement exécutés donc peu intéressant à automatiser.

c. Enfin des tests évoluant fréquemment coûtent cher à maintenir et ne sont donc pas intéressant à automatiser.

d. Il faut prioriser l’automatisation des tests. En premier les tests vitaux, puis une partie des tests de régression.

e. A vouloir trop (bien) faire on se retrouve souvent à ne rien faire du tout. Il faut savoir être pragmatique.

5.      Des tests mal écrits ou mal conçus

a. Les tests mal écrits ou mal conçus et donc sujet à interprétation sont des tests impossibles à automatiser correctement. Des tests manuels bien écrits sont la base pour commencer une automatisation.

b. Avoir des tests non stables est également un gros problème. Que peut-on dire d’un test qui est en succès 40% du temps et en échec 60% du temps ?

6.      Négliger la maintenance.

a. L’exécution de tests automatisés est quasiment gratuite, par contre la maintenance ne l’est pas. Avoir des tests non maintenus c’est pire que ne rien avoir.

b. Un test non maintenu fait croire que la fonctionnalité est couverte alors qu’elle ne l’est pas.

7.      Ne pas analyser les cas en échec

a. Ceci est un autre problème avec les tests automatisés. Souvent ils sont juste exécutés mais pas analyser. L’exécution seule ne sert à rien !

8.      Avoir des données et des environnements de test fiables et stables

a. En effet, avec les tests automatisés il n’y a pas de phase de préparation de l’environnement ou des données (si cette phase existe on perd une grande partie de l’intérêt de la rapidité d’exécution des tests). Cet environnement doit donc être toujours accessibles et stables et les données nécessaires aux tests bien présentes.

Encore merci à Ruslan Desyatnikov pour son article extrêmement pertinent.

Pensez à rejoindre le groupe Le métier du test si le test vous intéresse !

N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles

Une réponse

  1. Marc, merci pour la translation de cet article si pertinent.. Tous les arguments mis en avant sont d’une justesse incroyable. Pour arriver à cela l’auteur initial et ton apport ne laisse aucun doute sur les retours d’expériences cumulés très conséquent.

    Je me permets de

    A – Faire un focus sur le point

    3 -. Des membres de l’équipe pas assez bien formés

    b. Certains membres de l’équipe ne sont peut-être pas assez techniques et ont besoin d’une remise à niveau

    c. Certains membres de l’équipe peuvent avoir besoin de formation sur le langage de programmation qui sera utilisé pour l’automatisation.

    Très consommateur de temps et de ressource et donc de coût cette partie peut être annulée en faisant appel à un partenaire

    Et y ajouterai le point 10 (la solution est idem au point 3)

    10 – Implémenter une infrastructure de tests

    10 – 1 Pour des tests sur laptop

    10 – 2 Pour des tests sur device mobile
    Très belle journée
    Christian CloudNetCare

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

processus

La maturité des tests: pistes de réflexion (2/3)

Nous avons vu dans le premier article de cette série qu’il existe actuellement de beaux référentiels visant à évaluer le niveau de maturité des tests indépendamment du contexte. Ces modèles aussi bien soient-ils ont des limites. Ces limites sont par exemple: Afin de répondre à ces problématiques et rendre une

Lire la suite »
Image demandant une confirmation pour s'authentifier
culture générale

Article 1/3 : L’automatisation de tests dans un environnement sécurisé avec de l’authentification multi-facteur – Jonathan Bernales

1. Introduction aux mécanismes MFA dans le contexte du test Bienvenue dans cette série d’articles dédiée à une analyse approfondie du test de systèmes intégrant des mécanismes d’authentification multi-facteurs. Si vous travaillez dans une entité régulée, notamment dans les secteurs financier ou bancaire, vous avez probablement été confrontés aux défis

Lire la suite »
Interview Asli Le Dain Débuter dans le test en 2024
Interview

Interview: débuter dans le test en 2024

Bonjour Asli, peux-tu rapidement te présenter ? Bonjour, je m’appelle Asli et je suis testeuse technico-fonctionnelle en mission chez un client du secteur bancaire. J’ai récemment fait une reconversion professionnelle pour devenir testeuse après plus de 15 ans d’expérience professionnelle en immobilier d’entreprise. Peux-tu nous décrire ton parcours professionnel ? J’ai débuté

Lire la suite »