Utiliser la RPA pour tester des logiciels :un « hack technologique » ?

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

De temps en temps, mon fil d'actualités contient un article qui propose "Les 10 meilleurs piratages de la vie". Ce sont des trucs et astuces sur la façon d'utiliser des produits ménagers ordinaires de manière inattendue pour améliorer votre vie - "... et le conseil numéro 7 va vous époustoufler !!!"

Certes, j'ai été aspiré à ouvrir ce click bait. Pour être honnête, il y a des moments où je suis agréablement surpris. Par exemple, qui savait qu'il était possible de découper des blisters en plastique gênants avec un ouvre-boîte ou d'utiliser un rouleau de papier toilette pour empêcher le papier d'emballage de se dérouler ?

J'ai essayé les deux "hacks" ci-dessus et devinez quoi ? Ils ont "un peu" fonctionné… pendant un certain temps. L'ouvre-boîte a coupé à travers le joint où le plastique a été fusionné, mais il n'a pas réussi à couper à travers la longueur de l'emballage. Le rouleau de papier toilette a retenu le papier d'emballage pendant un certain temps, mais finalement le carton s'est affaibli et le papier d'emballage s'est effiloché. Sans surprise, l'utilisation de ciseaux pour les blisters en plastique et d'un petit morceau de ruban adhésif pour le papier d'emballage a beaucoup, beaucoup mieux fonctionné.

Dans le même ordre d'idées, de nombreuses organisations envisagent désormais d'utiliser la RPA pour automatiser les tests de logiciels :un "hack technologique" pour les tests de logiciels, en quelque sorte. Cependant, tout comme le rouleau de papier toilette ne présentait pas une solution durable pour empêcher mon papier d'emballage de se dérouler, la RPA n'est pas une solution durable pour l'automatisation des tests logiciels… et les modifications nécessaires pour rendre l'outil RPA durable pour la tâche de test logiciel l'automatisation serait, eh bien, un hack.

Si vous disposez déjà d'un outil RPA dans votre organisation et que vous souhaitez vous lancer dans l'automatisation des tests, votre outil RPA peut sembler un choix logique. Il est généralement relativement facile d'automatiser certains scénarios de test fondamentaux (par exemple, créer un nouvel utilisateur et effectuer une transaction), d'ajouter une validation et de croire que vous êtes sur la bonne voie pour tester l'automatisation.

Cependant, il est important de reconnaître qu'une automatisation des tests réussie et durable nécessite bien plus que la possibilité de cliquer sur les chemins d'application. Pour dépasser le lamentable taux moyen d'automatisation des tests de l'industrie de <20 %, les équipes doivent également être en mesure de construire et de 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 rencontrerez des obstacles à l'automatisation des tests tels que des retards dans l'attente des données de test et des 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 résultats clairs, commentaires exploitables.

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 API pour piloter des serveurs clients, des mainframes ou du code HTML. Un outil RPA fonctionne en cartographiant un processus dans le langage de l'outil RPA pour que le "robot" logiciel 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 gamme et une profondeur de produits et de fonctionnalités tout au long du cycle de vie du développement logiciel (SDLC). Cela comprend la conception et le développement des tests ; maintenance et réutilisation des 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 la prise en charge des tests continus. »

Le besoin de ces capacités de test supplémentaires devient clair lorsque vous considérez certaines des différences fondamentales entre :

• Automatiser les séquences de tâches dans les environnements de production pour exécuter avec succès un chemin clairement défini à travers un processus afin que vous puissiez terminer le travail plus rapidement, et
• Automatiser des processus métier réalistes dans tester des environnements pour voir où une application échoue afin que vous puissiez prendre des décisions éclairées pour savoir si une application est trop risquée pour être publiée

Que signifient ces différences pour les tests de logiciels ?

• L'automatisation doit s'exécuter dans un environnement de test généralement incomplet, évolutif et contraint
• La gestion de données de test avec état, sécurisées et conformes devient un énorme défi
• Une conception efficace des cas de test est essentielle au succès
• Les échecs doivent donner un aperçu du risque commercial

Pour le dire plus concrètement, prenons l'exemple du test d'un service de voyage en ligne. Supposons que vous souhaitiez vérifier la fonctionnalité qui permet à un utilisateur de prolonger sa réservation d'hôtel prépayée. Tout d'abord, vous devez décider du nombre de tests nécessaires pour exercer à fond la logique de l'application et des combinaisons de données que chacun devra utiliser.

Ensuite, vous devez acquérir et provisionner toutes les données nécessaires pour définir l'application dans l'état où le scénario de test peut être exécuté. Dans ce cas, vous avez besoin (au moins) d'un compte utilisateur existant avec une réservation prépayée existante pour une date future, et vous ne pouvez pas utiliser les données de production réelles, en raison de réglementations sur la confidentialité telles que 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 un carte de crédit.

Vous auriez besoin d'automatiser le processus, bien sûr. Il s'agit de se connecter, de récupérer la réservation existante, d'indiquer que l'on souhaite la modifier, puis de préciser la durée de l'extension.

Une fois que vous avez automatisé le processus complet, vous devez 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 d'utilisateurs ? 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 prolongée ? 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 d'origine plutôt que d'ajouter des nuits supplémentaires qui n'ont pas été payées ?

Imaginez maintenant que votre entreprise décide d'ajouter des frais de modification de 10 $ pour toutes les réservations prépayées. Pourriez-vous facilement intégrer cette nouvelle exigence dans vos tests automatisés existants ? Ou devriez-vous retravailler considérablement chaque test pour tenir compte de ce changement mineur ?

Même cet exemple simple expose certaines des nombreuses complexités de test de logiciels que les outils RPA ne sont tout simplement pas conçus pour résoudre. Les outils RPA sont conçus 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 conçus pour faire fonctionner un processus. Mais pour les tests de logiciels, vous avez besoin d'outils qui vous aident à déterminer comment un processus peut éventuellement se casser.

L'automatisation inefficace des tests logiciels est connue 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 numérique qui améliorent l'expérience client grâce à une livraison plus rapide des logiciels, lésiner sur les tests logiciels est contre-productif. Choisir le bon outil pour le travail sera considérablement rentable en termes d'accélération de la livraison, de réduction des risques commerciaux et de ressources supplémentaires à consacrer à l'innovation.

Wayne Ariola est l'auteur des tests continus pour les responsables informatiques et un conférencier bien connu dans l'espace DevOps et App Dev.