Jérôme Beaumont: le RPA appliqué au métier du test – les défis (3/3)

Les 4 défis de l’automatisation pour le test informatique

Se lancer dans un projet d’automatisation nécessite de relever les 4 défis suivants :

• faire face au foisonnement technologique,
• comprendre les assistants virtuels,
• relever le défi de la maintenance,
• obtenir un feedback rapide

Faire face au foisonnement technologique

L’assistant virtuel doit être capable d’interagir avec toutes les formes d’applications ou de services informatiques : applications web, ERP, applications bureautique, webservice, base de données, mainframe, traitement batch, IoT. Pour cela, l’offre RPA proposée par les acteurs historiques du marché est séduisante : UiPath, le leader actuel, Blueprism, un des premiers acteurs, Microsoft et son offre Power. Tous proposent des outils très puissants aux capacités techniques solides et qui ont fait leurs preuves, notamment dans les métiers du backoffice banque/assurance. Sont-ils pour autant bien adaptés au métier du test ? Le premier écueil est sans nul doute le coût de licence, alors que l’on souhaite que la phase de test soit la moins coûteuse possible. Le second écueil réside dans leur caractère « closed garden », qui rend l’assistant virtuel fermé aux technologies, en dehors de l’écosystème de l’éditeur. Le métier du test est fortement lié au produit logiciel qui est en constante évolution. La technologie sous-jacente à l’assistant virtuel doit pouvoir être étendue et ouverte en permanence. Ces contraintes poussent à adopter des technologies open-source, plus en phase avec la production du logiciel.

Il reste à choisir entre les trois tendances actuelles :

1. « code ». Dans cette configuration, l’assistant virtuel est un développement en langage informatique (java, C# par exemple). Il ne peut donc être réalisé et maintenu que par des ressources qui maîtrisent la programmation informatique : les développeurs. Cela peut devenir un handicap dans la mesure où ces compétences sont coûteuses, pas toujours disponibles et n’ont pas forcément d’appétence pour ce type de développement. Mieux vaut les centrer sur l’apport de valeur que constitue la création logicielle.
2. « no-code ». La promesse est de réaliser un assistant virtuel, soit à l’aide d’un enregistreur, soit par une description sous la forme d’un diagramme d’enchaînement d’étapes. Bien souvent, il faut adapter cet enregistrement pour lui permettre de traiter plus de situations (l’adapter aux données, le paramétrer, inclure des règles de comportement). L’effort de maintenance est souvent important. La recommandation est de réserver cette approche « quick and dirty » pour quelques situations non pérennes (on fabrique rapidement un automate jetable).
3. « low-code ». Dans cette approche, on utilise un langage de script le plus proche possible du langage naturel. Il est possible de faire monter en compétence des ressources fonctionnelles pour réaliser ces assistants virtuels. De plus, le script étant du texte, il peut facilement être mis en configuration au plus près du logiciel qu’il teste.

Robot Framework, basé sur Python, est un exemple de produit open-source de type « low-code ». C’est le couteau-suisse de l’automatisation.

Il bénéficie d’une grande communauté d’utilisateurs et de nombreuses librairies extensibles. Il permet de définir des mots-clés (« keywords ») qui sont des phrases en langage naturel. Cela permet d’adresser notre second défi : comprendre les assistants virtuels.

Comprendre les assistants virtuels

Pour obtenir le bénéfice de la documentation vivante, il est indispensable que la description de l’assistant virtuel soit la plus lisible possible. Cela renforce la collaboration au sein de l’équipe. On évite l’apparition de frontières, par exemple entre le développeur et le testeur. Dans ce contexte, utiliser un outil favorisant le langage naturel est clairement le meilleur choix. A titre d’exemple, dix lignes de codes Java sont nécessaires pour effectuer le lancement d’un navigateur web. Cela se résume au mot-clé « open browser » avec Robot Framework.

Dans le cas particulier de l’automatisation des tests, il est recommandé d’utiliser la méthode BDD (Behavior Driven Development) pour rédiger les cas de test. Le test, quand il est écrit en langage Gherkin, est alors découpé en trois déclarations :

1. Given « étant donné un client grand public », c’est l’étape de prérequis au test, pour obtenir un compte client par exemple. Il est recommandé de commencer avec un article indéfini pour matérialiser une situation, un état,
2. When « lorsque le client consulte son compte », c’est l’événement que l’on veut tester. On utilise une phrase sujet/verbe/complément pour matérialiser l’action,
3. Then « alors le solde doit être présent », c’est le résultat attendu du test. Le « doit être » met en évidence l’attendu

Avec cette méthode, le test automatisé est lisible par tous les acteurs du projet : développeur, testeur, product owner, métier. Le test est vérifié en continu à chaque changement du logiciel : c’est une spécification vivante qui permet de fournir en permanence l’état de la qualité du logiciel. Le test devient la formalisation d’une exigence, ce qui donne l’opportunité de préparer le test au moment de la conception du logiciel : c’est la démarche shift-left. Le test est décrit avant la fabrication du logiciel et va servir d’étalon de validation. Le gain de temps et de qualité est significatif.  Cette démarche de conception par le test permet de spécifier le comportement attendu avec des exemples concrets. L’équipe de conception reste ainsi dans le domaine du testable.

Il est essentiel que les tests automatiques soient fiables. Pour cela l’identification des faux-positifs est un élément-clé du succès. Il se trouve que la méthode BDD facilite ce diagnostic :

• L’échec de l’étape « Then » indique que l’objectif du test n’est pas atteint, alors que l’ensemble du scénario a été déroulé. Il y a un fort risque de bug dans ce cas.
• L’échec de l’étape « Given » ou « When » implique que le scénario ne s’est pas exécuté complètement. Il y a un risque de faux-positif associé à un problème d’environnement ou de jeux de données.

Les résultats de test doivent être disponibles, partagés et consolidés avec les tests manuels. Pour cela, il faut prévoir d’intégrer les résultats dans le référentiel des tests (par exemple avec JIRA/XRay). Cela permet de mettre en place un tableau de bord mis à jour au fil de l’eau des exécutions. La charge consacrée à la construction de reporting est alors libérée.

Disposer d’un script facilement compréhensible est aussi une première réponse au défi de la maintenance.

Relever le défi de la maintenance

Notre troisième défi est celui de la maintenance. La construction d’assistants virtuels ou de tests automatisés génère un effort de maintenance. Il s’agit d’adapter les scripts aux évolutions du produit logiciel testé ou de les rendre plus robustes. Cette charge peut vite devenir explosive avec l’augmentation du nombre d’automates. Dans le cas du test automatisé, il n’est pas rare qu’un test manuel aboutisse à la construction de cinq tests automatiques. En effet, pour faciliter le diagnostic d’un test, il est indispensable qu’il soit ciblé sur un seul objectif (un seul « Then »), alors que dans les tests manuels, il est fréquent que de nombreux contrôles soient effectués. On arrive vite à un patrimoine de plusieurs centaines de tests automatiques.

Fabriquer un automate est facile, en fabriquer des centaines maintenables est plus complexe. Il convient d’organiser la fabrication des automates en favorisant la réutilisation des mots-clés. La recommandation est de regrouper les mots-clés dans des bibliothèques aux responsabilités différentes :

1. le scénario de test, c’est l’histoire Given/When/Then,
2. les phrases métier, c’est le patrimoine automatisé qu’il faut gérer en bon père/mère de famille. L’idéal est de confier cette gestion à un responsable QA
3. les services applicatifs, ce sont des mots-clés d’action sur l’application métier à tester. Par exemple, se connecter, souscrire un contrat
4. les adaptateurs, c’est le socle technique commun à tous les projets. Par exemple, ouvrir le navigateur.

Cette méthode incite à la réutilisation des mots-clés. Il est possible d’atteindre des taux de réutilisation de l’ordre de 33%, c’est-à-dire qu’un mot-clé sur trois est utilisé plus d’une fois.

Avec des centaines de tests automatisés, les besoins en jeux de données sont fortement multipliés. Cela peut vite devenir une charge importante de maintenance. C’est le cas notamment lorsqu’on travaille avec des jeux de données statiques, spécifiques à chaque environnement de test. L’idéal est de construire des mots-clés qui vont permettre à l’automate d’obtenir son jeu de données automatiquement (jeux de données dynamiques).

Un fois la charge de maintenance maîtrisée, il est essentiel de s’assurer de la rapidité d’exécution des automates. C’est notre dernier défi, obtenir un feedback rapide.

Obtenir un feedback rapide

La réussite de l’automatisation est également liée à la rapidité du résultat. Une campagne de tests sur plusieurs heures rend difficile son adoption.  L’automaticien doit constamment être vigilant sur la durée d’exécution unitaire. Cependant, cela ne suffit pas. Il faut être capable d’exécuter des centaines de tests en un minimum de temps. Cette productivité passe par la parallélisation. Encore une fois, la méthode BDD rend plus facile cette étape car elle permet de concevoir chaque cas de test de manière indépendante. Le regroupement Given/When/Then constitue un test autonome qui peut être parallélisé.

Ensuite, l’usine de tests doit fournir des capacités de parallélisation en :

• s’appuyant sur les technologies de containerisation (docker swarm, kubernetes),
• en utilisant des grilles de navigateurs on-premise (grille selenium, par exemple) ou dans le cloud (solutions éditeurs de type saucelab ou browserstack),
• en s’intégrant aux chaînes d’intégration continue (Jenkins, Gitlab CI, Azure devops).

On peut aussi agir sur le volume de tests en ciblant le « juste effort ». La méthode traditionnelle est de faire une stratégie de test manuelle, pour cibler l’effort de test sur les risques. L’automatisation peut aussi apporter des solutions pour cibler les tests à rejouer. Par exemple, on peut utiliser des outils d’analyse de couverture de tests, pour construire la carte des modules utilisés par chaque test automatique. Ainsi, au moment du déploiement du logiciel à tester, il est possible, grâce au gestionnaire de version, de déterminer les tests à rejouer sur la base des modules livrés.

Vers de nouvelles évolutions du métier du test

Comme nous venons de le voir, la mise en œuvre d’une démarche RPA permet de répondre aux nouvelles exigences du métier du test : « plus fréquents, plus massifs, plus fiables ». Dans un monde où les mises en service ont lieu toutes les heures, la tâche ne peut plus être réalisée entièrement par des humains.

L’automatisation est une réponse qui ne vient pas en concurrence du test manuel mais en complément. La machine permet d’adresser un volume de tests important avec un temps d’exécution maîtrisé, sans perdre en vigilance.   Mais ces tests automatisés sont toujours identiques et sont vites atteints du paradoxe des pesticides :  on laisse passer les bugs qui ne sont pas ciblés par les tests. Il est clairement indispensable de compléter la couverture de tests automatiques avec des tests exploratoires manuels, car seuls les humains sont capables de trouver ces nouveaux bugs. Autant nous perdons en vigilance lorsque nous répétons toujours la même tâche, autant nous sommes très performants lorsque nous réalisons une activité créative. C’est d’ailleurs la devise de UiPath : « Nous concevons des robots pour que les gens ne deviennent pas des robots ».

La machine est extrêmement performante pour traiter des masses d’informations et trouver des corrélations infimes. C’est tout l’enjeu de l’intelligence artificielle. Cette nouvelle brique technologique disponible en open-source, notamment en Python, agit également dans l’évolution du métier du test. Il sera possible d’anticiper des corrections, de prédire des bugs, de mieux diagnostiquer, de choisir les tests à effectuer.

Nous avons vu que le test en continu et le shift-left sont une réponse au time to market. Une nouvelle tendance se fait également jour avec le test en production : le shift-right. Il s’agit d’une extension du métier du test sur l’exploitation du logiciel : tester, monitorer, diagnostiquer, anticiper tout dysfonctionnement.

Plus que jamais, le test est au cœur de la maîtrise de la fabrication, du déploiement et de l’exploitation informatique : un vrai métier.

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.