Un air de famille, mais des robots avec des caractères différents
La RPA (Robotic Process Automation) vise à automatiser des tâches manuelles informatisées pour un gain de qualité, de délai et/ou de coûts de production (Ex : saisir des données dans le SI, analyser et répondre automatiquement à une demande de prêt, traiter une demande de virement, etc.)
L’automatisation des tests vise à augmenter le nombre de tests exécutés à chaque campagne ainsi que la fréquence d’exécution de ces campagnes pour un gain en qualité (couverture de tests) et en rapidité de détection des anomalies. Il existe différents types et niveaux de tests, précisons immédiatement que les tests dont nous parlons ici sont essentiellement des tests logiciels de niveau système/UAT et de type boite noire (par opposition aux tests unitaires automatisés).
Il est donc à chaque fois question d’automatiser des actions effectuées dans des applications logicielles et il semble, à première vue, qu’une synergie naturelle devrait s’établir entre ces deux activités.
Dans la suite du document, nous allons passer en revue des éléments communs à la RPA et aux tests automatisés mais également leurs différences.
Des aspects techniques et humains similaires
Automatiser des actions sur une application consiste à développer un programme (ou robot logiciel) capable de solliciter cette application sans qu’elle puisse distinguer entre les actions d’un humain ou du robot.
Ceci implique de :
- Identifier les éléments de l’interface de manière fiable
- Conserver indépendamment du code les données d’identification de ces éléments
- Synchroniser le programme avec l’application
- Réagir aux comportements inattendus
Or toutes ces fonctionnalités sont partagées tant par les outils de RPA que par les outils d’automatisation de tests via la mise à disposition d’un environnement de développement no code, low code ou classique.
On constate que des développeurs passent de la RPA à l’automatisation de tests ou vice versa. Il n’y a donc pas de frein spécifique à ce niveau pour établir une synergie entre les deux activités.
Mais des différences structurantes
RPA
L’objectif de la RPA est de dérouler avec succès un scenario métier donné dans un environnement de production réputé stable et sans dysfonctionnement majeur.
Le résultat de l’exécution peut être :
- Réussi
- En exception métier. C’est-à-dire interrompu en raison d’une règle métier
- En erreur – une analyse devra identifier le défaut du code ou de l’environnement d’exécution.
L’implémentation d’un robot RPA se focalisera en priorité (en plus des exigences fonctionnelles) sur la fiabilité du robot et sa rapidité de traitement.
L’intégration à un outil de gestion et d’analyse de logs est primordiale afin d’évaluer la qualité du service en production et identifier les dysfonctionnements puis leur origine.
Tests automatisés
L’objectif des tests est de détecter des dysfonctionnements applicatifs dans un environnement potentiellement instable. Ceci se traduit par :
- Des cas non passant (Ex : vérifier le rejet d’une demande de prêt d’un mineur)
- Des tests partiels se concentrant sur une fonctionnalité particulière
- Des tests de bout en bout similaire à un scenario métier
Le résultat de l’exécution peut être :
- Réussi
- Echec – points de contrôles en échec
- Incomplet – Actions non déroulées
Le test automatisé se focalisera en priorité sur la détection des écarts vis-à-vis du comportement attendu, la fiabilité du test et enfin sur la rapidité de l’exécution.
Deux intégrations sont primordiales :
- Le gestionnaire de tests (description des tests, lien avec les exigences, jeux de données, campagnes de tests, résultats).
- Le CI/CD, dans un cadre DEV/OPS le déclenchement des tests automatisés est réalisé automatiquement par le CI/CD (ex : jenkins)
Synthèse
Les deux activités se différencient dans tout ce qui n’est pas pure automatisation de l’application.
- Le test automatisé est totalement autonome alors que l’humain peut intervenir avant, pendant et après un traitement RPA ce qui ajoute des contraintes à la RPA.
- Un test automatisé contient un très grand nombre de contrôlesdont seule une partie est nécessaire pour un robot RPA.
- L’interprétation du résultat de l’exécution diffère selon l’activité. Là où la RPA verra une exception métier à transmettre, le test ne verra qu’un succès ou un échec. Là où la maintenance RPA verra une erreur à corriger, le testeur verra un dysfonctionnement applicatif potentiel.
- Un robot RPA doit être fiable. Ceci implique de poursuivre son activité y compris en cas de dysfonctionnement temporaire de l’application.
L’automate de test doit alerter sur tous les dysfonctionnements et ne pas chercher à réaliser sa saisie à tout prix.
En cible : le partage de code
Les objectifs et l’implémentation étant différents, seuls les éléments fondamentaux d’automatisation seront partageables entre les deux activités :
- Les données techniques utilisées pour reconnaitre les éléments de l’interface – repository – peuvent être intégralement partagées
- Les actions élémentaires dans l’application comme démarrer une application, se connecter, se déconnecter, aller à un écran, etc.
Pour être réutilisable quelle que soit l’activité, l’automatisation des actions élémentaires doit être réalisée en étant déconnectée de la logique propre à chaque activité :
- Prérequis
- Contrôle et interprétation du résultat
- Gestion des exceptions
Atteindre ce résultat implique de concevoir et faire appliquer des règles d’écriture visant à garantir cette réutilisation. Ceci sera facilité par une organisation rassemblant les deux activités au sein d’une même équipe.
Conclusion
La majorité des éditeurs cherchent actuellement à faire converger leur produit pour qu’il offre les fonctionnalités et les intégrations nécessaires aux deux activités.
Il devient donc possible de créer une synergie entre RPA et automatisation de tests qui consisterait à partager l’identification des éléments de l’interface et des bibliothèques d’actions unitaires.
Toutefois créer cette synergie implique de partager des règles d’écriture, d’avoir un outil unique capable de supporter l’ensemble des contraintes de chaque activité et, de préférence, d’avoir une organisation qui regroupe ces activités au sein d’une même entité.
