La taverne du testeur

Automatisons ce qui compte le plus !

Les tests fonctionnels automatisés des applications web sont coûteux à concevoir et à maintenir. Et souvent, au fil du temps, ils perdent de leur pertinence vis à vis de l’usage réel en production. En apprenant de nos utilisateurs, nous pouvons tester ce qui compte le plus pour eux, en veillant à ce que notre suite de tests corresponde toujours aux parcours réels en production.

Dans cet article, nous décrivons une nouvelle approche des tests de régression des applications web, fondée sur la collecte des données d’usage anonymisées, la mesure et la complétion de la couverture des usages par les tests, et la génération automatique des scripts de tests automatisés.

L’automatisation des tests à partir de l’usage apporte trois bénéfices aux équipes en Agile et DevOps :

  • Explorer les parcours utilisateurs réels en production, leur fréquence, les cas particuliers et détecter des anomalies dans cet usage ;
  • Mesurer et optimiser la couverture de l’usage par les tests fonctionnels de régression automatisés ;
  • Réduire l’effort de création et de maintenance des scripts de tests automatisés de régression fonctionnelle.

Gravity est la plateforme d’automatisation des tests à partir de l’usage que nous développons et qui supporte les trois étapes principales du processus : 

  1. collecter la donnée d’usage anonymisée et faciliter son exploration,
  2. visualiser la couverture de l’usage par les tests et compléter cette couverture de façon assistée,
  3. produire et maintenir les scripts de tests automatisés.

Collecter la donnée d’usage anonyme

Connaître l’usage réel de nos produits par les utilisateurs est un sujet pour les équipes en Agile et DevOps. Souvent, nous n’avons qu’une idée générale de cet usage, et nous sommes parfois surpris lorsque nous découvrons des parcours utilisateurs auxquels nous n’avions pas pensé. C’est d’ailleurs fréquemment lors de l’analyse d’une anomalie en production que nous découvrons qu’un enchaînement d’actions est utilisé, d’une façon finalement correcte, mais non prévue. Est-ce un problème ? Pour l’usage du Produit, généralement pas. Mais, pour les tests automatisés : oui, car ce parcours utilisateur n’est alors pas testé en régression. Car tout écart entre ce que nous testons et l’usage réel diminue la valeur de nos tests, comme le rappelle le principe d’illusion d’absence d’erreur.

Gravity permet de collecter les actions utilisateurs et d’enregistrer la donnée d’usage anonymisée, en respectant la vie privée de l’utilisateur (sans aucune collecte de données personnelles). C’est toute la différence entre certaines pratiques, parfois peu respectueuses, du ciblage marketing, qui suivent le parcours d’un utilisateur donné (et connu).

Pour l’automatisation des tests à partir de l’usage, nous avons seulement besoin du pattern d’usage, c’est-à-dire des flots d’actions réalisées sur le Produit, indépendamment de qui les réalisent. Pour automatiser l’automatisation des tests à partir de l’usage, l’enregistrement d’une donnée totalement anonyme est parfait ! Pas de problème de RGPD ainsi. Gravity procède par l’ajout d’un simple script, qui permet la collecte des données anonymes et s’affranchit de l’obligation d’avoir des logs permettant de faire cette analyse.

Mesurer et compléter la couverture de l’usage par les tests

Collecter les traces d’usage en opération et aussi lors de l’exécution des tests permet de mesurer la couverture. La figure suivante montre la juxtaposition des traces d’usage en opération et lors de sessions d’exécution de tests (automatisés ou exploratoires).

Générer les scripts d’automatisation à partir des traces d’usage

La collecte des actions utilisateurs sur le front-end du Produit permet à la plateforme d’avoir les bonnes informations sur les objets graphiques pour forger les scripts d’automatisation. Nous avons choisi le framework d’automatisation Cypress pour mettre en place la création des scripts, comme première cible. La figure suivante montre l’exécution d’un script totalement généré et exécutable avec Cypress sur un exemple d’application eCommerce. Dans ce cas, le script automatisé généré automatiquement est directement exécutable, mais dans le cas général, nous visons 80% de réduction de l’effort, les 20% restant correspondent, par exemple, à une légère adaptation des scripts à des aspects particuliers du Produit, à l’ajout d’assertions particulières, et à la finalisation des données de test (qui ne peuvent pas être apprises de la collecte des traces d’usage).

Pour en savoir plus et aller plus loin

Cet article propose un aperçu d’une nouvelle approche de l’automatisation des tests fonctionnels de régression qui permet de se focaliser sur le test de ce qui compte vraiment par analyse de l’usage et l’optimisation de la couverture. L’automatisation de l’automatisation arrive en bonus par génération automatique du code des scripts d’automatisation. Pour vous permettre d’avoir une vision plus concrète du processus, vous pouvez accéder au replay du webinar intitulé “Des mises en production fréquentes et sûres grâce à des tests représentatifs de l’usage.

Vous pouvez aussi expérimenter, c’est direct et simple de mise en place; Contactez-nous à l’adresse gravity@smartesting.com et nous ferons un point de qualification avec vous sur votre contexte et échangerons sur vos objectifs d’automatisation.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Conception de cas de test

Tester des APIs!

Depuis plusieurs mois une question m’est posée de plus en plus fréquemment: comment tester une API ? Il est vrai que la taverne n’avait pas, à ce jour, d’articles spécifiques à ce sujet. Attention l’objet de cet article n’est pas de parler d’outil pour ces tests, il y en a

Lire la suite »

Principe 5 – Paradoxe du pesticide

Il arrive que de bons tests soient moins efficaces avec le temps, cette détérioration est due à un phénomène qui s’appelle le paradoxe du pesticide. La vidéo du Principe 5 explique ce paradoxe et propose des solutions pour limiter son impact. Les questions et commentaires des lecteurs améliorent la qualité du contenu et font plaisir

Lire la suite »
Conception visuelle

Retour Yest

J’ai eu la chance de pouvoir tester pendant 2 mois le logiciel Yest de Smatesting. C’est un logiciel récent basé sur du MBT (Model Based Testing) allégé. Présentation rapide : Le MBT c’est le fait de concevoir ses tests au travers de modèles (ou ici de schémas) écrits en amont. Le

Lire la suite »