Des critères d'acceptation par élément de travail transformables en tests

Objectif

Rendre la notion de « terminé » d'un élément de travail décidable avant que le travail ne commence, afin que la personne qui développe, la personne qui relit et celle qui a formulé la demande s'accordent sur les mêmes exemples.

Prérequis

Un élément de travail dont l'objectif est formulé (qui a besoin de quoi et pourquoi), un accès à la personne capable de répondre aux questions du domaine, et un emplacement où les critères figurent à côté de l'élément.

Étapes

1. Écrire la règle en une phrase, puis les exemples. La référence Gherkin décrit cette forme : un contexte initial (Given), un événement (When) et un résultat attendu (Then), et recommande 3 à 5 étapes par exemple afin qu'il reste lisible comme spécification.
2. Couvrir le cas principal, chaque cas limite et les chemins d'échec. Un ensemble de critères pour « limiter les téléversements à 10 Mo » comporte au moins : exactement 10 Mo accepté, 10 Mo plus un octet rejeté avec le message spécifié, et le rejet ne laissant aucun fichier partiel.
3. Utiliser des valeurs concrètes, pas des adjectifs : « le solde affiche 430 £ » plutôt que « le solde est correct ». Les exemples de Gherkin eux-mêmes opposent « il y a de l'argent sur mon compte » à « mon compte a un solde de 430 £ ».
4. Garder l'interaction utilisateur hors du Given, et garder les détails d'implémentation hors de tout le reste : les critères décrivent un comportement visible à la frontière que voit l'utilisateur ou le client.
5. Relire chaque critère et se demander : une personne chargée des tests qui n'a jamais vu le code pourrait-elle décider, à partir de ce seul texte, si c'est réussi ou échoué ? Si non, le réécrire.
6. Marquer ce qui est délibérément hors périmètre pour cet élément, afin qu'un reproche du type « il manque X » trouve sa réponse dans l'élément lui-même, pas dans la mémoire de chacun.
7. Avant l'implémentation, la personne qui développe propose tout exemple manquant ; la personne demandeuse confirme. Les désaccords trouvés à ce stade coûtent moins cher qu'en relecture.
8. Transformer les exemples en tests automatisés là où la frontière le permet (API, logique métier), et en liste de vérification manuelle là où ce n'est pas le cas (mise en page visuelle). Relier le test ou la liste de vérification depuis l'élément.

Résultat attendu

La relecture et l'acceptation deviennent une comparaison par rapport aux exemples listés ; la dérive de périmètre se manifeste comme un nouvel exemple à négocier plutôt qu'une hypothèse tacite.

Limites et base de vérification

Les exemples ne peuvent pas tout énumérer ; les exigences non fonctionnelles (latence, accessibilité) ont besoin d'une cible mesurable plutôt que d'un scénario. L'outillage Gherkin est facultatif ; la discipline réside dans les exemples, pas dans l'exécuteur. Méthode synthétisée à partir de la référence citée et de la pratique courante ; aucun effet sur le taux de défauts n'est revendiqué.