Exploiter la RPA pour les tests logiciels : une approche stratégique

L'automatisation inefficace des tests logiciels est notoire pour retarder les versions tout en consommant des quantités incroyables de ressources.

De temps en temps, mon fil d'actualités propose un article offrant « Les 10 meilleurs Life Hacks ». Ce sont des astuces sur comment utiliser des produits ménagers ordinaires de façons inattendues pour améliorer votre vie — « ...et l'astuce numéro 7 va vous épater !!! »

Admettons-le, je me suis fait avoir en ouvrant ce clickbait. Pour être honnête, il y a des moments où je suis agréablement surpris. Par exemple, qui savait qu'on pouvait couper à travers les emballages blister en plastique agaçants avec un ouvre-boîte, ou utiliser un rouleau de papier toilette pour empêcher le papier cadeau de se dérouler ?

J'ai essayé les deux « astuces » ci-dessus et devinez quoi ? Elles ont « un peu » marché... pour un moment. L'ouvre-boîte a coupé la couture où le plastique était fusionné, mais n'a pas réussi à couper sur la longueur de l'emballage. Le rouleau de papier toilette a tenu le papier cadeau un moment, mais finalement le carton s'est affaibli et le papier cadeau s'est déroulé. Pas surprenant, utiliser des ciseaux pour les emballages blister et un petit morceau de ruban adhésif pour le papier cadeau a marché beaucoup, beaucoup mieux.

Dans une veine très similaire, de nombreuses organisations envisagent maintenant d'utiliser la RPA pour automatiser les tests logiciels : un « tech hack » pour les tests logiciels, en quelque sorte. Cependant, tout comme le rouleau de papier toilette n'a pas présenté de solution durable pour empêcher mon papier cadeau de se dérouler, la RPA n'est pas une solution durable pour l'automatisation des tests logiciels... et les modifications requises pour rendre l'outil RPA durable pour la tâche d'automatisation des tests logiciels seraient, eh bien, un hack.

Si vous avez déjà un outil RPA dans votre organisation et que vous cherchez à démarrer avec l'automatisation des tests, votre outil RPA pourrait sembler un choix logique. Il est généralement relativement facile d'automatiser certains scénarios de test fondamentaux (ex : créer un nouvel utilisateur et compléter une transaction), ajouter de la validation, et croire que vous êtes sur la voie de l'automatisation des tests.

Cependant, il est important de reconnaître que l'automatisation des tests réussie — et durable — nécessite bien plus que la capacité de cliquer à travers des chemins d'application. Pour s'élever au-dessus du taux moyen lamentable d'automatisation des tests de l'industrie de <20 %, les équipes doivent aussi être capables de construire et stabiliser une suite de tests automatisés efficace. Les outils RPA ne sont généralement pas conçus pour permettre cela. En conséquence, vous heurterez des obstacles d'automatisation des tests tels que les délais d'attente pour les données de test et environnements de test requis, des résultats incohérents qui érodent la confiance dans l'initiative d'automatisation, et des suites de tests « gonflées » qui consomment des ressources considérables mais ne fournissent pas de retour clair et actionnable.

Pour un aperçu rapide de la différence de portée entre les outils RPA et les outils d'automatisation des tests, comparez les définitions suivantes de Gartner :

Les outils RPA « exécutent des instructions 'si, alors, sinon' sur des données structurées, généralement en utilisant une combinaison d'interactions d'interface utilisateur (UI), ou en se connectant à des APIs pour piloter des serveurs clients, mainframes ou code HTML. Un outil RPA fonctionne en mappant un processus dans le langage de l'outil RPA pour que le « robot » logiciel le suive, avec un temps d'exécution alloué pour exécuter le script par un tableau de bord de contrôle. »

Les outils d'automatisation des tests « permettent à une organisation de concevoir, développer, maintenir, gérer, exécuter et analyser des tests fonctionnels automatisés... Ils fournissent une largeur et une profondeur de produits et fonctionnalités à travers le cycle de vie de développement logiciel (SDLC). Cela inclut la conception et le développement de tests ; la maintenance et la réutilisation de cas de test ; et la gestion des tests, la gestion des données de test, les tests automatisés et l'intégration, avec un fort accent sur le support des tests continus. »

Le besoin de ces capacités de test supplémentaires devient clair quand on considère certaines des différences fondamentales entre :

• Automatiser des séquences de tâches dans des environnements de production pour exécuter avec succès un chemin clairement défini à travers un processus afin de compléter le travail plus vite, et
• Automatiser des processus métier réalistes dans des environnements de test pour voir où une application échoue afin de prendre des décisions éclairées sur le fait qu'une application est trop risquée pour être publiée

Qu'est-ce que ces différences signifient pour les tests logiciels ?

• L'automatisation doit s'exécuter dans un environnement de test qui est généralement incomplet, en évolution et contraint
• La gestion de données de test étatiques, sécurisées, conformes devient un énorme défi
• Une conception efficace de cas de test est essentielle pour le succès
• Les échecs doivent fournir un aperçu du risque métier

Pour le mettre en termes plus concrets, considérons l'exemple du test d'un service de voyage en ligne. Supposons que vous vouliez vérifier la fonctionnalité qui permet à un utilisateur d'étendre sa réservation d'hôtel prépayée. D'abord, vous devriez décider combien de tests sont requis pour exercer complètement la logique de l'application — et quelles combinaisons de données chacune aurait besoin d'utiliser.

Ensuite, vous devriez acquérir et provisionner toutes les données requises pour mettre l'application dans l'état où le scénario de test peut être exécuté. Dans ce cas, vous avez besoin (au minimum) d'un compte utilisateur existant avec une réservation prépayée existante pour une date future — et vous ne pourriez pas utiliser de données de production réelles, en raison de réglementations de confidentialité comme le RGPD.

Ensuite, vous avez besoin d'un moyen d'invoquer la gamme requise de réponses du système de réservation d'hôtel connecté (une chambre est disponible/non disponible), la carte de crédit (transaction approuvée/refusée) etc. — mais sans réellement réserver une chambre ou facturer une carte de crédit.

Vous auriez besoin d'automatiser le processus, bien sûr. Cela implique de se connecter, récupérer la réservation existante, indiquer que vous voulez la modifier, puis spécifier la durée de l'extension.

Une fois que vous avez le processus complet automatisé, vous devriez configurer un certain nombre de validations à différents points de contrôle. Les détails appropriés ont-ils été envoyés à l'hôtel dans le format de message approprié ? La réservation a-t-elle été mise à jour dans votre base de données utilisateur ? Les données de paiement ont-elles été correctement envoyées au fournisseur de carte de crédit ? Des crédits de compte ont-ils été appliqués ? L'utilisateur a-t-il reçu un message approprié si la réservation n'a pas pu être étendue ? Qu'en est-il si la carte de crédit a été refusée ? Et si la carte de crédit a été refusée, votre système est-il revenu à la durée de réservation originale plutôt que d'ajouter des nuits supplémentaires qui n'ont pas été réellement payées ?

Imaginez maintenant que votre entreprise a décidé d'ajouter des frais de 10 $ pour toutes les réservations prépayées. Pourriez-vous facilement glisser cette nouvelle exigence dans vos tests automatisés existants — ou devriez-vous substantiellement retravailler chaque test pour accommoder ce changement mineur ?

Même cet exemple simple expose certaines des nombreuses complexités des tests logiciels que les outils RPA ne sont tout simplement pas conçus pour adresser. Les outils RPA sont construits pour automatiser des tâches spécifiques dans une séquence. Les outils d'automatisation des tests logiciels sont conçus pour mesurer la résilience d'une séquence plus large de tâches. Pour le dire franchement : les outils RPA sont architecturés pour faire fonctionner un processus. Mais pour les tests logiciels, vous avez besoin d'outils qui vous aident à déterminer comment un processus peut éventuellement casser.

L'automatisation inefficace des tests logiciels est notoire pour retarder les versions tout en consommant des quantités incroyables de ressources. Alors que les DSI investissent de plus en plus dans des initiatives de transformation digitale qui améliorent l'expérience client grâce à une livraison logicielle plus rapide, lésiner sur les tests logiciels est contre-productif. Choisir le bon outil pour le travail paiera significativement en termes de livraison accélérée, risque métier réduit, et plus de ressources à dédier à l'innovation.

Wayne Ariola est l'auteur de Continuous Testing for IT leaders et un conférencier keynote bien connu dans l'espace DevOps et App Dev.