Un test, une fonctionnalité : jusqu'où doit aller un test ?

Au moment d'écrire un test, une question revient toujours : est-ce que je mets tout dans le même, ou est-ce que je découpe ? Notre réponse tient en une ligne. Un test ne vérifie qu'une seule chose à la fois.

Un test sert surtout le jour où il échoue. Ce jour-là, il doit vous dire ce qui ne va pas. S'il a vérifié cinq choses d'affilée, il vous dit seulement que quelque chose, quelque part, ne va pas. Plus le test porte de choses, moins sa réponse est nette.

« Plus le test est petit, plus le test est fiable. »

Arnaud, qui a créé Qaviar

La règle vient de la méthode expérimentale

En science, un essai se construit autour d'un témoin, c'est-à-dire une version de référence que l'on laisse intacte pour pouvoir comparer. On change un seul paramètre, on observe, puis on recommence avec un autre. Si l'on change la température et la dose en même temps et que le résultat bouge, impossible de dire lequel des deux a joué. L'essai ne prouve rien.

Le test d'un site obéit à la même logique. Quand il revient en erreur, deux questions se posent : qu'est-ce qui a déclenché le changement, et quel paramètre a créé l'écart ? Un test qui ne vérifie qu'une chose y répond de lui-même. Il désigne une cause.

Un test qui en vérifie plusieurs vous laisse une liste de suspects. Il faut alors refaire à la main ce que le test devait faire pour vous : reprendre chaque étape, une par une, jusqu'à trouver laquelle a cédé. Le test a coûté du temps à écrire et n'en fait pas gagner au moment où il le devrait.

Une consigne qui vérifie tout à la fois

Imaginons une consigne comme celle-ci, pour une boutique en ligne :

« Créez un compte, ajoutez trois produits au panier, passez le site en anglais, appliquez un code promotion, inscrivez-vous à la lettre d'information et vérifiez que le pied de page affiche les mentions légales. »

Le test échoue au code promotion. Que faut-il corriger ?

Plusieurs réponses sont possibles, et le test ne permet pas de choisir. Le code lui-même pourrait être en cause : mal saisi, expiré, ou réellement défaillant, et c'est justement ce qu'on voulait savoir. Le compte tout juste créé aussi : le code pourrait être réservé à certains clients, ou le compte avoir été mal enregistré. Les trois produits ensuite : le code pourrait ne pas s'appliquer à l'un d'eux, ou le panier ne pas les avoir gardés tous les trois. Reste le passage en anglais, qui pourrait avoir modifié le panier, à moins que le code ne soit reconnu que dans une seule langue.

Quatre pistes, aucune exclue. Voilà le premier coût d'un test trop gros.

Le second se voit moins. La lettre d'information et les mentions légales venaient après le code promotion. Le test s'est arrêté avant elles : son résultat « en erreur » ne dit rien de l'inscription, rien du pied de page. Deux des six fonctionnalités n'ont jamais été vérifiées.

La même consigne, découpée, donne six tests : la création du compte, le panier, le changement de langue, le code promotion, l'inscription à la lettre d'information, les mentions légales du pied de page. Si le code promotion échoue, les cinq autres disent ce qui fonctionne, et l'échec désigne sa fonctionnalité sans hésitation.

Plusieurs étapes, une seule vérification

« Une seule chose » ne veut pas dire « une seule action ». Pour vérifier une chose, il faut souvent en faire d'autres avant.

Pour vérifier qu'un compte est bien créé, il faut d'abord l'enregistrer : remplir le formulaire, valider. Pour vérifier qu'un produit est bien au panier, il faut évidemment l'y mettre. Ces étapes ne sont pas des vérifications supplémentaires. Elles servent à arriver au point que l'on veut contrôler.

La différence se joue dans ce que le test attend. Dans le test du code promotion découpé plus haut, il faut un produit au panier, sinon il n'y a rien à quoi appliquer le code. C'est une étape. En revanche, ce test ne revérifie pas que le compte a été créé correctement, ni que la langue a changé : d'autres tests s'en chargent. S'il échoue, c'est sur le code.

Un test peut donc compter plusieurs étapes, tant qu'il ne contrôle qu'une chose à la fin.

La limite : le chemin le plus court

Reste à savoir où commencer et où s'arrêter. La règle que nous appliquons : on part de la vérification visée et on ne garde que le chemin le plus court qui y mène. Tout détour ajoute une deuxième chose testée.

Prenons le panier d'un client connecté. Le test consiste à se connecter, mettre le produit au panier, puis vérifier le panier. Trois étapes, toutes indispensables : sans connexion, ce n'est pas le panier d'un client connecté ; sans produit, il n'y a rien à vérifier. C'est un test acceptable.

À l'inverse, reprenons la longue consigne. Passer le site en anglais avant d'appliquer le code promotion, alors que le test ne porte pas sur la langue, est un détour. Il n'aide en rien à vérifier le code. Il ajoute seulement une cause possible d'échec : c'était l'une des quatre pistes.

Pour chaque étape, une question suffit : sans elle, puis-je encore atteindre la vérification ? Si oui, elle sort du test.

« Testez tout le site » n'est pas une consigne

Parmi les consignes que l'on voit écrire, certaines vont plus loin que l'exemple du code promotion : « testez tout le site », « testez la partie client ». C'est le cas extrême de la même erreur. Il n'y a plus plusieurs choses à vérifier, il n'y en a aucune de nommée.

Le test obtenu n'est pas fiable, parce que personne n'a dit ce qu'il devait trouver. Il parcourt des pages, peut-être beaucoup. Mais son résultat ne vous dit pas si ce qui compte pour vos clients fonctionne, puisque ce qui compte n'a jamais été écrit. Décider de ce qui doit marcher reste le travail de l'équipe ; nous l'expliquons dans ce que l'IA change, et ne change pas, au test d'un site.

Dans Qaviar, un test s'écrit comme une consigne en phrases courantes. Tout ce qui précède s'applique à cette consigne : une consigne, une fonctionnalité.

La réécriture part de la question « que doit pouvoir faire un client ? ». « Testez la partie client » devient alors une série de consignes, une par chose : créer son compte, se connecter, modifier son adresse, retrouver ses commandes. Chacune a son test, chacune dit oui ou non.

Ouvrez votre consigne la plus longue et comptez les « et » et les « puis ». Pour chaque vérification qui n'est pas indispensable à la dernière, écrivez un test à part.