Pourquoi automatiser ? Quelles activités automatiser ?

Pourquoi automatiser ?

Avant d’automatiser il faut savoir pourquoi l’on souhaite le faire. Il ne faut pas se le cacher, se lancer dans un projet d’automatisation c’est initier une démarche qui demandera de nombreux effort et qui est semées de pièges à éviter… ou à résoudre lorsque l’on y est confronté. Il est donc important, avant de commencer à automatiser, de savoir pourquoi l’on veut automatiser et si le jeu en vaut la chandelle.

Les raisons d’automatiser pour les entreprises

Lorsque l’on aborde le sujet de l’automatisation de l’exécution des tests ou de toute autre activité d’automatisation du test, on met en avant les intérêts de l’entreprise qui développe le logiciel. Ces intérêts sont divers et variés mais on peut, pour simplifier les diviser en 4 familles :

Le gain ou plus exactement l’économie d’argent

Cette raison est la raison principale mise en avant dans les entreprises. Les tests, encore plus dans les méthodes Agiles, peuvent vite coûter cher. L’automatisation d’une activité de test (le plus souvent l’automatisation de l’exécution) est donc un investissement qui vise un retour sur investissement à moyen terme. Ce retour sur investissement est d’ailleurs l’objet d’un indicateur qui vise à le calculer, le fameux ROI. Cet indicateur reste assez complexe à calculer car il faut être capable d’évaluer les coûts exacts des diverses activités manuelles et automatisées.

Il est bon de noter que le retour sur investissement se fait rarement sur le court terme mais plutôt sur le moyen terme. Etant conscient de cette caractéristique il m’est arrivé de faire le choix dans un contexte particulier d’urgence (produit à délivrer en 3 mois) de décider de ne pas me lancer dans l’automatisation afin de ne pas investir du temps et de l’argent dans une automatisation qui n’aurait pas pu offrir un retour sur investissement dans le temps imparti… Et qui aurait même mis en péril la date de livraison du produit.

Le gain de temps

Le gain de temps ne veut pas forcément dire gain d’argent !  Dans certains contextes on peut être amené à vouloir automatiser certaines activités même si l’on sait que le retour sur investissement financier ne sera pas présent (c’était d’ailleurs l’objet de mon premier audit).

Le critère du gain de temps est un critère difficilement chiffrable et mesurable (même s’il existe des indicateurs pour cela) mais prépondérant dans le choix d’automatiser. En effet ce gain de temps peut par exemple permettre de :

• Réaliser l’ensemble des tâches nécessaire dans le temps imparti
  • Libérer du temps au testeurs pour s’atteler à des tâches à plus forte valeur ajoutée comme travailler sur de l’amélioration continue (amélioration de processus, amélioration des campagnes…)
  • Mettre à disposition plus tôt le logiciel, une de ses versions ou plus simplement des fonctionnalités ou correctifs de dernier.
  • Faire plus de tests afin d’assurer une meilleure couverture (ce qui est en rapport avec la 4^ème famille)
  • Implémenter l’intégration continue dans une démarche DevOps

Le DevOps, que je considère personnellement simplement comme de l’Agile qui englobe vraiment l’ensemble des acteurs travaillant sur un produit, rime souvent avec chaine d’intégration continue (même si les chaînes d’intégration continue sont des outils et donc non liée à la démarche DevOps). Ces chaînes d’intégration continue qui peuvent aller jusqu’au du déploiement continu, c’est-à-dire un déploiement direct sur l’environnement de production, nécessitent des tests (voir le prochain chapitre dédié aux tests dans la démarche DevOps). Les chaînes d’intégration continue se doivent d’être rapide. Personne n’accepte qu’une simple fusion de branche (merge) prennent plus de 15 minutes ! La seule manière de répondre à ce besoin de rapidité est une automatisation de l’exécution des tests. Cette automatisation est d’ailleurs parfois insuffisante et force à s’adapter en proposant une parallélisassions des tests ou encore en retravaillant la campagne (moins de test, sélection de test, optimisation du temps d’exécution des tests en eux même…)

« Améliorer la qualité »

Ce point est souvent mis en avant par les entreprises. L’automatisation doit améliorer la qualité du logiciel ! Cela peut être le cas dans le sens où l’automatisation des tests peut permettre de :

• Tester plus tôt et donc potentiellement corriger des anomalies qui n’auraient pas pu être corrigées plus tard (car trop cher)
  • Tester plus (plus de tests) et plus souvent avec une campagne automatisée complétée par des tests exploratoires
  • Libérer du temps pour améliorer les processus

Néanmoins, l’automatisation n’engendre pas forcément une amélioration de la qualité. Il est d’ailleurs fréquent d’avoir au début des projet d’automatisation une baisse de cette dernière de par l’investissement mis pour l’automatisation ou encore de failles dans cette automatisation.

Les raisons d’automatiser pour les personnes

Automatiser pour des raisons liées à l’entreprise c’est naturel et obligatoire. Il ne faut cependant pas oublier que derrière ces stratégies d’entreprise il y a des personnes… Et que ces personnes peuvent également avoir leurs propres raisons de vouloir automatiser.

Cet axe peut être traité en 2 points :

• Quels sont les leviers de motivation pour l’automatisation

Nous n’aborderons pas ce point dans ce chapitre car il est particulièrement bien développé dans l’article de Zoé Thivet présent dans la dernière partie de ce livre.

• Pourquoi, de manière générale les testeurs automatisent leurs activités

L’automatisation est en fait naturelle dans notre vie de tous les jours. Nous y faisons appel instinctivement tous les jours et ce depuis l’enfance. Cette automatisation instinctive se fait souvent lorsque l’on se retrouve dans l’un des 2 cas suivants :

• Lorsque nous sommes soumis à l’exécution d’une tâche répétitive

L’automatisation des tâches répétitives dépasse le simple cadre du logiciel. On le voit notamment dans l’industrie. Il est fini le temps du film « les temps modernes » ou notre Charlot préféré se retrouver à serrer des boulons pendant des heures. Cette tâche particulièrement répétitive a été automatisée.

Cette automatisation des tâches ingrates, répétitives et à faible valeur ajoutée ne se limite d’ailleurs pas uniquement au travail ou à l’âge adulte ! En effet je me remémore régulièrement avec un léger sourire le concours de « techniques » utilisées à l’école par mes camarades et moi-même lorsqu’il s’agissait de faire nos punitions. Ces punitions étaient généralement la copie de (trop) nombreuses lignes d’une phrase n’étant généralement pas particulièrement très recherchée et qui ressemblait généralement à : « je ne parlerai plus à mon voisin pendant les cours ». Nos techniques allaient de l’utilisation d’un papier calque (pas très efficace), à l’utilisation de plusieurs stylos en simultanés en passant par la tentative de le rendre en version Word imprimée ou même demander à des copains de nous aider en faisant quelques lignes (à charge de revanche !).

Tous ces moyens de limiter l’impact de la punition sont en fait des prémices de l’automatisation de tâches à faible valeur ajoutée et faible valeur actuelle. Le type de tâche sur lesquelles on veut passer le moins de temps possible pour passer à autre chose.

• Lorsque la probabilité d’erreur dans la tâche que nous exécutons est forte

L’automatisation c’est aussi l’outillage. Qui n’a pas souvenir de suites d’actions simples à faire mais qui au final s’avère être un calvaire car il y a de très nombreuses actions qui se suivent et qu’au final on se trompe ? Cela arrive souvent lorsque l’on est encore à l’école et que l’on doit résoudre des problèmes. Au début, pour éviter ce genre de problème on décide simplement de faire des vérifications et de refaire plusieurs fois la suite d’actions pour s’assurer que notre résultat est le bon… Sauf que généralement si l’on ne s’est pas trompé la première fois il reste probable que l’on se trompe lors de la vérification… Ce qui nous fait perdre énormément de temps.

Un exemple concret est celui du calcul de moyenne (technique utilisée par ma professeure de mathématiques en 1^ère et que j’ai réutilisée ensuite). Une moyenne c’est une somme de toutes ses notes divisé par le nombre de notes. Les nombres à additionner sont souvent très grands, la somme devient alors compliquée avec une probabilité d’erreur importante. Il est possible de remplacer toutes les notes par une note à laquelle on soustrait la moyenne (10). La moyenne effective devient plus facile à calculer car les nombres à manipuler sont plus petits comme on peut le voir avec l’exemple ci-dessous:

Notes: 12; 14; 8: 13; 15 donne (2 + 4 – 2 + 3 + 5)/5 + 10 = 12/5 + 10 = 12,4 de moyenne

Que retenir ?

Nous automatisons nos activités pour plusieurs raisons.

D’un point de vue les objectifs de l’automatisation des activités de test est généralement lié à un besoin de limitation des coûts et/ou des délais ou des impératifs comme une amélioration de la qualité ou la nécessité d’avoir de l’automatisation dans le cadre d’une stratégie basée sur la mise en place de chaines d’intégration continue.

D’un point de vue humain les objectifs sont principalement lié à du ressenti et au besoin d’éviter un mal-être. Ce mal-être est généré par l’accumulation de tâches répétitives à faible valeur ajoutée (et entrainant l’ennui) ou au stress de l’erreur de par l’accumulation des actions.

Fort heureusement les objectifs, même différents ne se contredisent pas. En effet on peut voir que dans les 2 cas, l’automatisation est mise en place pour :

• Nous faire gagner du temps :  gain de temps et d’argent ainsi que l’intégration continue pour les entreprises ; éviter de passer trop de temps sur certaines tâches pour les testeurs.
  • Améliorer la qualité : objectif direct pour les entreprises, éviter les erreurs sur certaines tâches et l’ennui (qui induit un manque de concentration) sur d’autres pour le testeur

Cela peut être résumé avec ce schéma :

Quelles activités automatiser ?

 Quelle activité pensons-nous lorsque l’on parle d’automatisation dans le test ?

Instinctivement lorsque l’on parle d’automatisation de test ou de ses activités on pense à l’automatisation de l’exécution des tests. Cette vision est dû, au moins en partie, à l’image encore persistante du travail de testeur qui ne fait qu’exécuter des tests. Il est intéressant de noter que cette vision peut aussi expliquer en partie pourquoi certaines personnes voient arriver la fin des testeurs avec la démocratisation des méthodes agiles.

Cet instinct visant à automatiser l’exécution des tests scriptés semble néanmoins cohérent lorsque l’on réfléchit à l’activité de l’exécution de ces tests et qu’on le passe au prisme des objectifs de l’automatisation.

En effet, l’exécution des tests scriptés est une activité qui prend du temps à des testeurs qui sont payés (temps et argent pour l’entreprise), une activité incompatible avec l’intégration continue et qui pousse à ne pas tester trop souvent (impact qualité). De même, surtout en Agile cela peut vite devenir une tâche rébarbative pour le testeur ce qui entraîne une hausse des probabilités d’erreur lors de l’exécution.

L’exécution des tests scriptés est donc une candidate parfaite à l’exécution des tests mais est-ce la seule ?

Quelles activités de test pouvons-nous concrètement automatiser ?

Cela n’est évidemment pas le cas. La vie d’un testeur ne se résume fort heureusement pas à l’exécution de tests scriptés. Un testeur a de nombreuses activités variées qu’il serait trop long d’énumérer de manière exhaustive. On peut néanmoins citer des activités très fréquentes comme :

• La conception de tests
• La préparation des campagnes (données, environnements, tests…)
• La maintenance des tests
• L’exécution de sessions de tests exploratoires
• L’analyse des résultats des campagnes
• L’implémentation et l’amélioration les processus de test
• L’initiation et la contribution au plan de test
• La création et le suivi des fiches d’anomalie
• En Agile : participer aux activités de l’équipe et faire des tâches non spécifiques au testeur…

Certaines de ses activités sont à forte valeur ajoutée. Je pense notamment à la conception et l’exécution des campagnes de test. Néanmoins, même pour ces activités il existe des étapes ou des actions qui ont moins de valeur ajoutée et qui peuvent être automatisées. C’est d ‘ailleurs pour cela que des outils de MBT (comme Yest et MaTeLo) pour la conception et des outils de support au tests exploratoires (comme AIFEX) pour existent.

D’autres activités ont moins de valeurs ajoutées et peuvent donc être des candidates à l’automatisation (au moins en partie) très intéressantes. Je pense notamment à :

• La maintenance des tests de régression

Cette maintenance peut vite être chronophage et fastidieuse. Elle est d’ailleurs une cause majeure des échecs des projets d’automatisation des tests. Fort heureusement elle peut être automatisée en partie ! Une manière d’automatiser partiellement la maintenance est de concevoir un automate de test avec une architecture modulaire qui adopte les bonnes pratiques du code (notamment avec une bonne factorisation). Cela permet de mettre à jour en 1 fois chaque étape commune à plusieurs tests!

• L’édition des bilans des campagnes

L’édition des bilans des campagnes est une tâche particulièrement importante. Le bilan est la vitrine des tests, c’est LE document qui sera consulté par les non testeurs, c’est LE document qui importe… Bref c’est le fruit de tout le travail du testeur sur une campagne. De manière générale il semble donc peu intéressant de l’automatiser. Néanmoins, on remarque qu’avec la multiplication des campagnes (avec l’automatisation des tests scripts) et la standardisation du contenu du bilan de ces dernières cette tâche peut vite devenir fastidieuse mais aussi un goulot d’étranglement. Dans ce cas il devient nécessaire d’automatiser, au moins en partie ces bilans en fonction du résultat des tests. Pour cela il sera probablement obligatoire de définir certains critères liés à des indicateurs comme donner un « Go » uniquement si aucun bug n’est remonté par la régression.

• La gestion des environnements et des données de test

La création d’environnement de test est primordiale pour pouvoir tester efficacement, c’est d’ailleurs un élément obligatoire pour être TMMI niveau 2. Il est même parfois conseillé d’avoir un environnement créé spécialement pour chaque campagne (cela assure la présence des données) pour être impacté le moins possible par des éléments extérieurs. Cette création est néanmoins assez technique et chronophage ce qui explique que selon le CFTL le métier de gestionnaire des environnements de test est un métier à part entière. De plus, elle fait appel à des compétences que n’ont pas forcément les testeurs. Il semble donc intéressant d’automatiser ces créations d’environnement ce que fait un outil comme Docker.

Il est important de rappeler qu’il n’existe pas d’environnement de test et de test sans données de test. Il est donc nécessaire de créer les environnements avec les données nécessaires ou encore générer ces données après la création des environnements ce qui peut permettre, dans certains contextes, de vérifier que la création d’éléments proposés par le logiciel fonctionne correctement.

• L’écriture des cas de test après leur conception

La conception est une étape essentielle et peu automatisable. Néanmoins, après avoir conçu son test, si ce test est destiné à être scripté il faut l’écrire. Cette écriture se doit d’être rigoureuse et, si possible, permettre une maintenance limitée… Cette activité peut vite se retrouver fastidieuse et technique sans proposer de forte valeur ajoutée, ce n’est pas un hasard si les tests exploratoires la suppriment.

Les outils de MBT comme Yest et MaTeLo aide fortement à l’automatisation de cette partie en proposant même d’aller jusqu’à l’écriture de script automatisés pour Yest et une exécution de ces derniers pour MaTeLo.

• La création des fiches d’anomalies

Les fiches d’anomalies sont des livrables particulièrement important dans lesquels il faut mettre autant d’informations que possible afin que n’importe quel acteur sur le logiciel (métier, testeur, développeur) puisse la reproduire et la comprendre. Ces paramètres peuvent être très nombreux et il est facile d’en oublier. Là encore l’automatisation peut nous aider en pré-remplissant des informations permettant de reproduire l’anomalie.

Conclusion

On peut avoir un intérêt à automatiser, au moins en partie, toute activité de test. Automatiser l’ensemble de ces activités est néanmoins une mauvaise idée dans la quasi-totalité des contextes. En effet, à vouloir tout automatiser on peut vite se retrouver devant une machine qui sera très peu compréhensible, très peu flexible mais aussi particulièrement cher et ennuyante à maintenir… Ce qui rendrait l’automatisation contre-productive par rapport à ses objectifs définis précédemment.

Pour savoir ce qu’il est intéressant d’automatiser il faut avant toute chose connaitre l’impact des diverses activités et voir ce que leur automatisation partielle ou complète peut apporter. De même, il est important de prioriser les activités que l’on souhaite automatiser. Pour cela je conseille généralement de cibler les « points de douleurs ». Qu’est-ce qui nous dérange ? Qu’est-ce qui nous ralentit ? Qu’est-ce qui nous handicap ? Lorsque l’on sait répondre à ces questions-là priorisation des activités de test à automatiser devient une évidence et il devient alors possible d’étudier l’intérêt d’automatiser les activités que nous souhaitons automatiser. Il est alors temps de réfléchir à l’automatisation de ces activités.

Tout comme pour l’automatisation de l’exécution des tests scriptés afin de réussir l’automatisation de toute activité de test il faut  :

• Définir les objectifs liés à l’automatisation de l’activité en question
• Identifier les solutions existantes et étudier un retour sur investissement (financier ou non) potentiel
• Choisir une solution, qui peut être un logiciel acheté ou un développement interne, si l’on décide d’initier l’automatisation de l’activité suite au point précédent
• Implémenter la solution à travers un POC (Proof Of Concept)
• Prioriser les tâches
• Faire un bilan et mesurer les avancées

Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test

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

N’hésitez pas à faire vos propres retours d’expérience en commentaire.