La recette utilisateur est le moment où les personnes qui vont réellement se servir du logiciel décident s’il fait leur travail. Non pas s’il fonctionne - cela a déjà été testé - mais s’il fait ce qu’elles avaient demandé, d’une manière avec laquelle elles peuvent vivre.

C’est la seule phase de test dont l’objet est une décision plutôt qu’une liste d’anomalies. La recette se termine par quelqu’un qui dit oui ou non à une mise en production.

Ce qui la distingue de tous les autres tests

Chaque phase antérieure demande si le logiciel est conforme à sa spécification. La recette demande si la spécification était la bonne.

Cette distinction paraît théorique jusqu’à ce qu’on la voie à l’œuvre. Une fonctionnalité peut passer tous les tests fonctionnels, satisfaire chaque critère d’acceptation tel qu’il est écrit, et être malgré tout refusée en recette parce que la personne qui fait ce geste trois cents fois par semaine voit qu’il lui faudra quatre clics là où l’ancienne façon en demandait un. Rien n’est cassé. C’est l’exigence qui était fausse, et c’est le dernier moment peu coûteux pour s’en apercevoir.

Tests QA
Le logiciel fait-il ce que nous avions annoncé ? Menés par des testeurs, contre la spécification
Recette utilisateur
Fait-il ce dont le métier a besoin ? Menée par ceux dont c'est le travail, contre la réalité

Qui la mène, et qui ne devrait pas

Les gens qui vont s’en servir. Ni l’équipe de développement, ni la QA, ni un manager qui les remplacerait.

C’est plus difficile qu’il n’y paraît. Les personnes que vous voulez sont occupées à faire le travail pour lequel le logiciel existe, et leur temps est la partie la plus chère de tout l’exercice. C’est pourquoi une recette planifiée après coup finit déléguée à qui est disponible, et une mise en production se retrouve validée par quelqu’un qui n’a jamais fait le travail qu’elle sert.

Deux rôles méritent d’être nommés : quelqu’un à qui appartient la décision et qui peut dire non, et quelqu’un qui rassemble ce que les testeurs trouvent et en fait quelque chose d’exploitable par un développeur. Sans le premier, la recette produit des avis et aucune issue. Sans le second, elle produit un tableur dont personne ne peut rien faire.

Ce qu’il faut donner aux testeurs

Pas une liste de fonctionnalités. Une liste de ce qu’ils font d’habitude.

1. Mener un nouveau client de la demande jusqu'à la première facture
2. Traiter un remboursement pour une commande payée par carte
3. Clôturer le mois avec deux agences qui déclarent séparément
4. Corriger une adresse sur une commande déjà expédiée

Ce sont des processus métier, et chacun traverse plusieurs fonctionnalités. Un testeur à qui l’on dit « vérifiez l’écran des factures » vérifiera l’écran des factures ; un testeur à qui l’on dit « menez un nouveau client jusqu’à sa première facture » trouvera les deux endroits où le processus casse entre deux écrans, et c’est là que vivent les vrais problèmes.

Donnez-leur de vraies données, ou la copie sûre la plus proche. Une recette sur une base de Client de Test 1 à 20 ne trouve aucun des problèmes qu’un client nommé « O’Brien & Sons (anciennement Smith) » trouve immédiatement.

Quand elle est terminée

Avant de commencer, mettez-vous d’accord sur ce que « oui » veut dire. Par écrit, et en des termes que quelqu’un peut vérifier.

  • Quels processus doivent fonctionner, et lesquels ont le droit d’être pénibles
  • Ce qui compte comme bloquant, par opposition à ce qui se corrigera à la prochaine version
  • Qui signe, et ce qu’il signe
  • Combien de temps elle dure. Une recette sans date de fin ne se termine pas ; elle s’éteint

L’échec le plus courant n’est pas un mauvais test, c’est une fin floue. Une phase qui dure jusqu’à ce que les gens cessent de remonter des choses se termine quand ils s’en lassent, et une version livrée par lassitude est une version que personne n’a approuvée.

Les remontées que produit une recette

C’est la partie que les équipes de développement redoutent, et la raison en est structurelle plutôt que la faute de quiconque.

Vos testeurs ne sont pas des testeurs. Ce sont des comptables, des régulateurs, des infirmiers, des commerciaux - et ils décrivent ce qui s’est passé dans la langue de leur métier plutôt que dans celle du logiciel. « La facture est partie à la mauvaise agence » est une phrase parfaitement claire et elle n’est pas reproductible. Il y manque quelle facture, quelle agence, ce qu’il y avait à l’écran et ce qu’ils attendaient à la place.

Deux choses aident plus que tout le reste :

Demandez le déroulé, pas le diagnostic. « Qu’étiez-vous en train de faire, et que vous attendiez-vous à voir ? » vous mène plus loin que n’importe quel formulaire, parce que l’hypothèse d’un utilisateur métier sur la cause est le plus souvent fausse et remplace le plus souvent les faits.

Retirez-leur la partie technique des mains. Personne en recette ne devrait avoir à fournir une version de navigateur, un journal de console, ou des étapes rédigées pour un développeur. Bien faire cela, c’est le rôle de l’outillage, et moins vous demandez à un testeur, plus il remontera de choses.

Session Replay

Extension Chrome gratuite. Un clic sur la page qui se comporte mal capture la copie d'écran, la console et le journal réseau, et vous rend un lien à coller dans le ticket.

Installer l'extension

Celui qui rassemble les remontées doit toujours faire de chacune quelque chose d’exploitable par un développeur, et le guide du rapport de bug en donne la forme. Si une trouvaille de recette ne peut pas être reproduite, elle sera close sans résolution, aussi réelle qu’elle ait été.

La version courte

La recette demande si le logiciel fait le travail, et la réponse appartient à ceux dont c’est le travail. Donnez-leur des processus plutôt que des écrans, de vraies données plutôt que des lignes de test, une définition convenue du oui, et le moins de devoirs techniques possible. Ce qui reviendra sera formulé dans leur langue, et en faire quelque chose de reproductible est le travail, pas le signe qu’ils ont mal testé.