On vous demande de tester une fonctionnalité sans aucune spécification écrite. Comment procédez-vous ?

Construisez la spécification en testant plutôt que d'en attendre une. Recueillez l'intention auprès de la personne qui l'a demandée, regardez des fonctionnalités existantes similaires pour les conventions, explorez la fonctionnalité pour cartographier son comportement réel, et écrivez ce que vous trouvez sous forme d'énoncés testables. Faites-les ensuite confirmer par le responsable produit, pour que les ambiguïtés remontent en questions avant la livraison plutôt qu'en bugs contestés après.

Je n'attends pas de document et je ne devine pas non plus, parce que deviner veut dire que chaque trouvaille se transforme en débat sur le fait que ce soit un bug ou non. Je commence par chercher l'intention là où elle existe : le ticket, la maquette, un fil de discussion, la description de la pull request, et une conversation de dix minutes avec la personne qui a demandé la fonctionnalité, où j'attaque par quel problème cela résout pour l'utilisateur. Ensuite je regarde des fonctionnalités comparables dans le même produit, parce que la cohérence est elle-même une exigence et qu'un nouvel écran qui valide différemment de tous les autres est un défaut, quoi qu'en dise n'importe quel document. Puis j'explore la fonctionnalité et j'écris ce qu'elle fait réellement sous forme d'énoncés testables. Cela devient une courte spécification, en général une page environ, et je la renvoie avec les ambiguïtés signalées : quand la quantité dépasse le stock, est-ce que cela bloque ou est-ce que cela avertit ? Neuf fois sur dix le responsable produit répond dans l'heure, et nous avons désormais une définition partagée du correct avant la livraison plutôt qu'un litige après. Cela laisse aussi de quoi travailler au testeur suivant.