La validation se définie à la conception
Une demande n’est pas prête tant que personne ne sait à quoi on reconnaîtra qu’elle est correctement réalisée. C’est pour cela que le processus de validation s’écrit dans le ticket, au moment de la conception, et pas quand le ticket arrive en À valider .
Deux choses doivent y figurer :
- qui valide et comment, en une ligne pour une demande simple, en plusieurs actions assignées pour une demande qui se valide en plusieurs temps
- les règles de validation elles-mêmes, c’est à dire les cas concrets qui prouvent que le comportement attendu est respecté
La personne assignée doit pouvoir lire le ticket et comprendre non seulement ce qu’elle doit faire, mais également ce sur quoi son travail sera validé. Sans cela, elle avance au doigt mouillé et découvre le périmètre de la validation au moment où il est trop tard pour l’ajuster (personne ne devrait accepter de travailler dans ces conditions, c’est le meilleur moyen de faire déraper un projet et de détruire la motivation des équipes).
Des cas concrets, pas seulement la théorie
La description d’un ticket énonce une règle de façon théorique. Cela ne suffit pas : nous confirmons le comportement attendu par des exemples concrets, qui pourront être implémentés tels quels sous forme de tests automatisés.
Lors de la rédaction de ces cas de test, il faut commencer par les cas d’erreur et les cas limites. Ce sont eux qui font remonter les règles de gestion manquantes. Les cas nominaux, eux, sont déjà dans la tête de tout le monde.
L’usage de cas concrêts et représentatifs du métier est le seul moyen de confirmer que la conception a été réalisée de manière pragmatique sans oublie dans le périmètre et permet de limiter les risques de mauvaise interprétation de partie de la demande.
Un exemple complet : le calcul d’un âge
Prenons une règle décrite ainsi dans un ticket :
L’âge d’une personne s’affiche sous la forme Y an(s) et M mois, calculé à partir de sa date de naissance.
- Si l’âge est inférieur à 1 an, afficher seulement le nombre de mois.
- Si l’âge est inférieur à 2 ans, afficher “an” sans le “s”.
- Si le nombre de mois est égal à 0, afficher Y an(s) sans la partie mois.
- Les chiffres sont arrondis à l’entier inférieur.
La règle paraît complète. Elle ne l’est pas encore : il manque ce qui se passe pour une date de naissance dans le futur, et personne ne l’a remarqué avant d’écrire les cas.
Voici la décomposition, calculée à une date de référence fixée au 18 septembre 2023.
Cas d’erreur
- Naissance le 1er octobre 2023, soit une date future
Cas valides
- Naissance le 25 septembre 2023 : 0 mois
- Naissance le 25 août 2023 : 1 mois
- Naissance le 17 septembre 2022 : 12 mois
- Naissance le 18 septembre 2022 : 1 an
- Naissance le 18 octobre 2022 : 1 an et 1 mois
- Naissance le 18 septembre 2020 : 3 ans
- Naissance le 18 décembre 2017 : 6 ans et 3 mois
Chaque ligne correspond à un cas de test et chaque possibilité de la règle est couverte : le passage du mois à l’année, le pluriel, l’arrondi à l’entier inférieur, le cas où les mois tombent à zéro.
La date de référence est fixée dans le cas de test, jamais prise sur la date du jour. Un test dont le résultat dépend du moment où on le lance devient faux tout seul et on apprend à ne plus le croire.
Ce que ce travail change
Écrire ces cas avant le développement produit trois effets, dans cet ordre :
- La conception se complète. Ici, le cas de la date future était absent de la règle. Il aurait été découvert en recette, ou pire, en production.
- La personne assignée sait où elle va. Elle dispose d’une liste de cas à faire passer, pas d’une interprétation à défendre.
- La validation se réduit l’essentiel. Sur cet exemple, la partie calcul se valide en lisant les tests automatisés. Le travail de validation interne se limite alors à vérifier l’affichage dans la page ou dans l’export.
C’est ce troisième point qui évite la sur-qualité comme la sous-qualité : nous ne retestons pas à la main ce qu’une suite de tests couvre déjà et nous ne laissons pas passer sans contrôle ce qu’elle ne couvre pas.