Ce que l'IA change au test d'un site, et ce qu'elle ne change pas

Ajouter un produit au panier. Créer un compte client. Saisir un code promotion et vérifier que la réduction s'applique. Sur une boutique en ligne, ces vérifications reviennent après chaque modification du site, et elles se font le plus souvent à la main.

Arnaud, qui a créé Qaviar, les a faites pendant des années :

« En tant que développeur Magento depuis plus de dix ans, j'ai dû tester des centaines de fois les mêmes parcours sur de nombreux sites différents : “Vérifier que le produit s'ajoute au panier”, “Vérifier que le compte client est bien créé”, “Vérifier la bonne application du code promotion”. Ce sont autant d'heures qui n'ont pas été utilisées pour ajouter des fonctionnalités, mais pour détecter des bugs ou des régressions. »

Magento est une plateforme de boutique en ligne répandue. Une régression, c'est une fonction qui marchait et qui ne marche plus après une modification faite ailleurs dans le site. Les heures dont parle Arnaud ne servent pas à construire le site. Elles servent à s'assurer que rien n'a bougé depuis la dernière fois.

Ce qui se répète peut être confié à la machine

Ces tests ne sont pas superflus. Sans eux, ce sont les clients du site qui découvrent les problèmes, et leur mécontentement arrive avec.

On les appelle des tests de non-régression : on les refait pour vérifier qu'une modification n'a rien cassé ailleurs. Leur intérêt tient justement à ce qu'ils ne changent pas. Le parcours d'ajout au panier de cette semaine est celui du mois dernier. Entre les deux, seul le site a pu bouger.

C'est ce qui les rend automatisables. Un test qui se refait à l'identique n'a besoin de personne pour décider quoi faire. Il a besoin d'être refait, et que quelqu'un dise si le résultat a changé. Le temps qu'une personne y passe est nécessaire au bon fonctionnement du site, mais il ne produit rien d'autre que la réponse « oui, ça marche encore ». Avec l'IA, il nous paraît inconcevable qu'un humain doive encore refaire ces gestes à la main, mise en ligne après mise en ligne.

C'est de ce constat qu'est parti Qaviar. Les tests s'y écrivent en langage courant, par exemple « vérifier que le produit s'ajoute au panier ». Ils restent donc lisibles par un chef de projet ou un client qui n'est pas développeur. Ils sont ensuite rejoués à l'identique. Quand un rejeu montre un écart confirmé, sa page en explique la cause probable. C'est là, pour nous, que se trouve la vraie valeur ajoutée : savoir pourquoi le résultat a changé.

Rejouer ne suffit pas pour autant à tester un site.

Ce qui reste à l'humain : décider ce qui compte

Certains tests ne peuvent pas être entièrement automatisés : ceux qui touchent à un cas particulier, ou qui demandent un jugement. Ce sont souvent les plus risqués, et ceux qui pèsent le plus sur une mise en ligne : un profil de client à part, une situation exceptionnelle.

Prenez un cas qui arrive tous les jours. Une boutique en ligne vend aussi à des professionnels, qui ont des prix négociés. L'un d'eux passe commande et saisit un code promotion. Personne, en écrivant les tests, n'avait prévu cette combinaison.

Le code doit-il s'appliquer au prix négocié, au prix public, ou pas du tout ? Un test automatique peut relever le prix affiché. Il ne peut pas dire si ce prix est juste, parce que la réponse n'est pas dans le site. Elle est dans la règle commerciale de l'entreprise, et seul quelqu'un qui la connaît peut dire si le montant est le bon.

Il faut d'abord avoir pensé à poser la question. Un test vérifie ce qu'on lui a demandé de vérifier. Il ne s'inquiète pas d'un client auquel personne n'a pensé.

Reste à savoir qui pose ces questions. Cela dépend vraiment du contexte.

Le client est à l'origine de la demande. Il ne sait pas toujours ce qu'elle implique côté code, et ce n'est pas ce qui compte pour lui : il juge sur le résultat. Des tests simples lui permettent de dire à l'avance ce qu'il attend, par exemple le prix que doit voir son client professionnel quand il saisit un code.

Le chef de projet, quand il s'implique, fait le lien entre le client et les développeurs. Il traduit la demande du client en tests fonctionnels, c'est-à-dire en vérifications décrites du point de vue de celui qui utilise le site.

Le développeur, lui, doit toujours tester son propre travail : vérifier que ce qu'il a mis en place fonctionne comme demandé, et qu'il n'a pas introduit de bug.

Aucun de ces trois rôles ne disparaît quand les tests répétitifs sont automatisés. Chacun récupère du temps, et ce temps va à la partie qui demande de réfléchir : trouver le client à part, la situation que personne n'avait prévue.

Faire le partage sur votre propre site

Aucun outil n'est nécessaire pour commencer. Reprenez chaque vérification faite avant une mise en ligne et posez-lui deux questions.

D'abord : se refait-elle à l'identique d'une mise en ligne à l'autre ? L'ajout au panier, la création d'un compte, un code promotion sur une commande ordinaire répondent oui. Mêmes gestes, même résultat attendu. Ces vérifications peuvent être confiées à l'automatisation.

Ensuite : faut-il, pour la faire, penser à un utilisateur ou à une situation précise ? Le client professionnel qui saisit un code en fait partie. Ces vérifications restent à votre équipe.

Pour la seconde liste, il faut aussi savoir qui formule les cas : le client en décrivant le résultat qu'il attend, le chef de projet en le traduisant en tests, le développeur pour son propre travail.

Vous pouvez faire l'exercice avant la prochaine mise en ligne. Prenez la liste des vérifications de la précédente, ou écrivez-la s'il n'y en a pas, et marquez d'un trait tout ce qui a été refait exactement comme la fois d'avant. Ce qui est marqué est la part à ne plus faire à la main.