Jérôme Beaumont: le RPA appliqué au métier du test – l’évolution du métier de testeur (1/3)

Introduction

L’acronyme RPA pour Robotic Process Automation est un nouveau buzzword incontournable de l’IT. Cet article a pour objectif d’exposer le contexte du métier du test et en quoi le RPA peut être une réponse à ces enjeux autour de quelques retours d’expérience : bienvenue dans le monde de l’automatisation appliquée au métier du test. Dans de nombreux domaines, les nouveaux services digitaux proposés par les entreprises ont accéléré les mises en service. Les projets informatiques ont dû s’adapter à cette nouvelle contrainte du « time to market ». Cette transformation touche à la fois le produit logiciel et son mode de fabrication :

• La conduite de projet passe du cycle en V au mode Agile avec des équipes resserrées aux compétences élargies : développeur, testeur, opération.
• La conception de la solution migre du modèle 3-tiers on-premise vers des architectures micro-services compatibles avec le cloud.
• Les exigences augmentent notamment celles sur les performances, la sécurité et sur l’expérience client qui doit prendre en compte les terminaux mobiles.

Dans ce contexte, le métier du test informatique est en forte évolution. Il doit répondre à la double contrainte de rapidité d’exécution et de réduction des coûts. Dès lors, l’automatisation peut être une première réponse à ce double défi.

Le métier du test en forte évolution

La phase de test sur un projet est la phase la plus difficile. Historiquement positionnée en séquence avec la phase de réalisation du produit logiciel, elle est alors sur le chemin critique du projet et soumise à la contrainte de la date de mise en service rarement négociable. En méthode Agile, les sprints sont de 2 à 3 semaines, ce qui met la durée de la phase de test sous une forte contrainte, de l’ordre de 2 à 3 jours au sein d’un sprint, parfois 5 jours sur le sprint de release où on décide de faire une campagne pour vérifier la non-régression. On comprend tout de suite que la phase de test, ainsi positionnée, devient un goulot d’étranglement du projet. Ce constat a fait naître les initiatives autour du shift-left, c’est-à-dire intégrer l’effort de test au fil de l’eau de la fabrication des user stories, afin d’éviter l’accumulation de tests en fin de sprint. Le mouvement TDD (Test Driven Development) en est une forme de réponse,  le développeur est ainsi chargé de mettre en place un test au sein de son code, avant de développer les évolutions demandées. Cette méthode est très efficace pour adresser les tests unitaires et permet d’inclure les tests avec le code. En contrepartie, elle ne peut pas adresser la totalité des niveaux de test de la pyramide et elle positionne le développeur en juge et partie de la qualité.

De plus, l’augmentation des exigences aboutit à une véritable explosion combinatoire de cas de test, humainement non atteignable. Pour réduire cette combinatoire et focaliser l’effort de test, il faut appliquer une stratégie de test basée sur l’évaluation du risque d’un dysfonctionnement et de son impact. Dans un contexte de temps fortement contraint, il est difficile de systématiser cette approche qui reste une évaluation le plus souvent « à dire d’expert », où il faut évaluer le risque de chaque changement (Risk Base Testing). Au moment de la mise en service, il est également indispensable de connaître factuellement la qualité du produit, ce qui implique un effort de traçabilité de tous les résultats de test et, pour chaque test, de connaître l’exigence qualité qu’il couvre.

La pression sur les coûts est également très forte. La phase de test est par nature en spirale, c’est-à-dire que son coût peut être difficile à maîtriser puisqu’il est lié à la maturité du logiciel testé. Moins le logiciel est mature, plus longue sera sa phase de validation.

On voit bien les nouveaux enjeux se dessiner :

• tester plus rapidement pour répondre au time to market,
• tester plus massivement pour répondre aux exigences qualité,
• tester plus efficacement pour maîtriser les coûts.

« Plus fréquent, Plus massif, Plus efficace » : c’est la devise olympique que les méthodes de tests actuelles doivent relever. Lorsque j’ai quitté SFR en 2015, les mises en service avaient lieu une fois par mois, chez Pages jaunes en 2017 c’est une mise en service chaque semaine, chez Amazon c’est une mise en service toutes les heures. Le test basé sur la seule ressource humaine n’est tout simplement plus envisageable.

A propos de l’auteur:

Jérôme Beaumont est advenced architect RPA and Test Automation chez Altran part of Capgemini. Depuis 2017, il diffuse la pratique d’automatisation de tests sur les plateaux Altran et conseille les entreprises dans l’industrialisation de leur processus métier. Il a actuellement la charge de déployer le RPA sur l’ensemble des opération Cap Gemini Engeneering France.