Livre CFTL: Évolution et état des lieux de l’automatisation

Article écrit à 4 mains avec Bruno Legeard

Introduction : L’automatisation partie intégrante du test

L’automatisation de l’exécution des tests constitue une large part de l’activité des testeurs comme on peut le constater avec l’enquête du CFTL de 2019 où moins de 10% des organisations n’ont pas de tests automatisés, mais aussi dans la figure ci-dessous issue de l’enquête « State of Software Testing 2021 ».

Dans ce graphique, l’activité d’automatisation concerne 75 % des participants à l’enquête et arrive en premier.

Figure 1 – L’automatisation dans l’activité des testeurs

L’automatisation de l’exécution des tests s’est installée dans ce paysage des tests logiciels de manière pérenne comme le montre les sondages de 2018 et 2021 de la taverne du testeur où l’automatisation des tests (exécution et autres activités) occupe largement la première place des thèmes d’avenir du test :

Ce succès n’a pour autant pas été immédiat et est le fruit d’une lente évolution toujours en cours et des évolutions de l’industrie du logiciel en général, mais aussi en lien avec l’évolution du cycle de développement des logiciels (Agilité, DevOps) et l’évolution de l’outillage d’automatisation.

Les débuts de l’automatisation de l’exécution des tests

Lorsque l’on parle d’automatisation des tests on pense avant tout à l’automatisation de l’exécution des tests. Cela est logique tant l’exécution des tests scriptés est une tâche à faible valeur ajoutée et représentative d’un travail fastidieux pour les testeurs. Je pourrais même ajouter que l’idée de l’automatisation de l’exécution des tests est aussi vieille que l’exécution des tests elle-même… Elle a donc fait l’objet de nombreuses expérimentations.

Les premières tentatives d’automatisation de l’exécution des tests étaient une automatisation du type « record and replay »… Il est d’ailleurs assez inquiétant de noter que pour certaines personnes l’automatisation de l’exécution des tests restent sous cette forme. Le principe était simple, on enregistrait les actions (mouvement de souris, clic, entrer du texte sur le clavier…) et on les rejouait. Ce type d’automatisation s’est vite révélée très mauvaise pour différentes raisons. Les principales étant une maintenabilité quasiment nulle, une dépendance très forte aux « outils » utilisés (taille de l’écran, sensibilité de la souris) et à des changements graphiques même légers. Au final cette première génération d’automatisation de l’exécution des tests s’est avérée plus fastidieuse et plus coûteuse que l’exécution manuelle des tests. Ce fut donc un échec sur toute la ligne mais un échec qui a permis au test d’avancer et de s’améliorer !

Des premiers essais les testeurs et l’ensemble des ingénieurs logiciels ont conclu que l’automatisation de l’exécution des tests ne s’improvisait pas, que c’était un projet de développement à lui tout seul. Les tests sont alors devenus des morceaux de code utilisant des fonctions et enchaînant des actions. Les fonctions appelées utilisent des paramètres pour identifier les éléments avec lesquels on souhaite interagir ou que l’on souhaite vérifier. Ce changement a permis d’améliorer la stabilité, la fiabilité et la maintenabilité des tests. Néanmoins cela a rendu cette automatisation technique (peu abordable à des profils fonctionnels) mais aussi coûteuse ce qui a fait émerger des indicateurs comme le retour sur investissement (ROI).

La seconde étape de l’automatisation de l’exécution des tests ayant été concluante elle a été améliorée en adoptant des bonnes pratiques du code comme la factorisation de parties des tests ce qui a permis d’améliorer à moyen terme le retour sur investissement de l’automatisation en diminuant les coûts de maintenance. L’automatisation restait néanmoins un outil assez peu développé avant l’émergence de nouvelles méthodes de développement avec la démocratisation des méthodes Agile !

La généralisation de l’automatisation de l’exécution des tests

Les développements en Agile sont devenus la norme comme on peut le voir avec l’enquête 2019 du CFTL :

Cette proportion de développement en Agile continue d’ailleurs à augmenter avec une nécessité pour les marchés du numérique et du logiciel à être toujours plus réactif en faisant face à des utilisateurs toujours plus exigeants dans un marché toujours plus concurrentiels et en constante évolution.

Cette généralisation de l’Agile n’est pas sans conséquence sur le test. Comme vous pouvez le lire dans le premier livre du CFTL publié en 2019, un développement en Agile c’est un développement itératif proposant de petites évolutions régulières aux utilisateurs du produit. Ces déploiements qui étaient auparavant limités à moins de 5 par an peuvent maintenant se retrouver sur une échelle totalement différente avec plusieurs déploiements dans la journée. De manière générale on observe actuellement des déploiements qui correspondent à la fin de chaque sprint donc de l’ordre d’un déploiement toutes les 2 à 4 semaines. Cette multiplication des déploiements nécessite une multiplication des exécutions. Ce qui faisait barrière à l’automatisation avec un ROI parfois difficile à atteindre n’est plus un sujet ! Ne pas automatiser l’exécution de ces tests revient à ne plus pouvoir livrer ou ne plus pouvoir proposer une campagne de régression suffisante.

L’automatisation de l’exécution des tests est donc devenue la norme ! On demande donc maintenant aux testeurs d’automatiser ces tests… ce qui nous amène à un autre problème, une proportion non négligeable de testeurs n’a pas les compétences techniques pour automatiser des tests. Cette problématique a vite été repérée c’est pourquoi de nombreuses formations sont proposées. Au-delà de la formation de nouveaux outils d’automatisation plus accessibles aux profils fonctionnels sont apparus. Je parle ici des outils de Keyword Driven Testing (KDT) dont le représentant le plus connu est Robot Framework mais il y a aussi des outils encore plus accessibles comme Agilitest et Horustest. Le but de ces outils est de proposer des tests beaucoup plus lisibles, compréhensibles. Cela permet donc à des profils fonctionnels de pouvoir plus aisément maintenir et scripter des tests automatiser. Ces outils représentent également un très bon point d’entrée pour comprendre l’automatisation des tests et ses contraintes.

L’extension de l’automatisation des tests à l’ensemble des activités de test

L’automatisation de l’exécution des tests est maintenant assez mature dans de nombreuses entreprises ou équipes. Ces dernières sont néanmoins toujours soumises à des problématiques de temps toujours plus contraignantes. Le temps d’exécution des tests n’est maintenant plus vraiment un problème pour ces équipes. Les goulots d’étranglement sur les tests se trouvent maintenant sur d’autres activités qui, il y a encore quelques années n’attiraient pas l’attention mais qui de nos jours peuvent devenir des points de tensions. Ces goulots d’étranglement ne sont plus forcément les mêmes en fonction des équipes et peuvent impacter toutes les activités de test.

La conception et l’écriture des tests peut prendre un temps non négligeable. Il peut donc être intéressant d’automatiser ces activités avec des outils de Model Based Testing (MBT) comme Yest ou MaTeLo. Cette automatisation de la conception et de l’écriture des tests est d’ailleurs le principal axe d’évolution de l’automatisation d’après le rapport du World Quality Report 2019-2020 :

Comme vous pourrez le constater dans ce livre il y a de nombreuses autres activités qui peuvent être automatisées comme les indicateurs, l’édition des bilans la gestion de la traçabilité mais aussi la maintenance des campagnes de test qui font de plus en plus face au paradoxe des pesticides.

L’émergence de l’IA dans le support aux activités de test

Depuis plusieurs années, l’IA pour le test a d’abord été un slogan : les techniques d’intelligence artificielle allaient changer la donne et remplacer les testeurs. En 2021, nous n’en sommes plus là ! L’IA, et plus précisément les algorithmes d’apprentissage automatique – Machine Learning en anglais – commencent à infuser, de façon pratique et utile, dans l’outillage de support aux activités de test.

En effet, les algorithmes d’apprentissage automatique permettent d’analyser des données pour classer ces données, prédire une situation, ou générer de nouvelles données. L’apprentissage sur des données permet de mettre en place un modèle capable, en fonction de la qualité des données utilisées (et donc avec un risque de biais) de réaliser l’une et/ou l’autre de ces tâches.

Ces capacités de classement, prédiction et génération ont une forte utilité dans le support à de nombreuses activités de test. Citons en quelques-unes :

• Classification
  • Classer des anomalies pour éliminer les faux-positifs, automatiser l’analyse d’impact et l’identification des causes
  • Classer des logs pour visualiser les patterns d’usage des logiciels par les utilisateurs et identifier les parcours à couvrir
  • Reconnaissance d’objets IH/M pour la maintenance des tests automatisés
  • Analyse comparée du rendu d’une application web sur différents navigateurs par apprentissage sur les images du rendu et détection d’anomalies
• Prédiction
  • Prédiction d’anomalies dans un système
  • Sélection & priorisation des tests à exécuter (cf. chapitre II-x)
  • Estimation de risques pour une release
  • Estimation de l’effort de test à partir de l’extraction de différentes caractéristiques d’une base de projets
• Génération
  • Génération de données de tests à partir de l’apprentissage sur les cas en production
  • Génération de scripts de test à partir des logs en production par analyse de patterns d’usage
  • Correction d’objets GUI dans un script d’automatisation pour l’auto-maintenance des tests automatisés

Ce ne sont que des exemples, mais qui montrent le large panel d’activités de test que les techniques d’apprentissage automatique peuvent aider à réaliser. Cela implique en premier lieu d’avoir des données d’apprentissage de qualité, ce qui constitue une barrière importante pour plusieurs de ces activités. Prenons l’exemple de l’estimation de l’effort de test à partir d’une base de projets. Si l’enregistrement des données de suivi de ces projets a été réalisée de façon incomplète ou même inexacte, alors les algorithmes d’apprentissage ne pourront pas fonctionner correctement. C’est la même chose sur la classification des anomalies, il faut que le référentiel de données soit suffisamment complet et fiable.

D’autres applications, comme la génération de tests de régression à partir de l’analyse des traces d’exécution (cf. chapitre II-y), s’appuient sur les traces d’usage enregistrée dans le suivi analytique ou dans les logs, qui constituent un ensemble de données existants, volumineux et disponibles. Ces données de production sont de plus présentes car nécessaire au monitoring applicatif, et elle constitue un réservoir qui ne demande qu’à être exploité pour les tests.

L’arrivée de l’IA – de l’apprentissage automatique – pour l’automatisation des activités de test est devenu une réalité de 2021, mais aussi un axe fort du renforcement de cette automatisation pour les années à venir. Car finalement, l’activité d’un testeur est pour une grande partie l’analyse de données disponibles, et une IA peut aider car les algorithmes d’apprentissage sont faits pour cela.

Conclusion

L’automatisation de l’exécution des tests a mis du temps à s’imposer dans le monde du test. Il a fallu le développement de l’Agile pour la rendre indispensable et utilisé par la grande majorité des équipes. Le développement de cette activité a permis de  définir de nouvelles activités d’amélioration afin de permettre aux testeurs de répondre aux contraintes de l’Agile et du marché qui sont une réactivité et une adaptation toujours plus rapides.

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.