Idée principale

« Une commande facturée ne reçoit plus de ligne » est une affirmation vérifiable. Elle n'a pas besoin d'être traduite pour devenir un cas de test : elle nomme un état, une action et un verdict. Quelques centaines de règles écrites de cette façon sont autant de tests candidats que personne n'a eu à déduire d'un fichier source.

La même phrase rend un second service, sur un autre bureau. Devant un signalement client, la question cesse d'être une affaire d'expérience et devient mécanique : le comportement observé contredit-il une règle écrite — c'est un défaut ; ou aucune règle ne couvrait le cas — c'est une décision produit qui n'a jamais été prise. Sans corpus de règles, ce verdict est rendu à l'ancienneté, par la personne qui se souvient.

Pourquoi c'est important

Cela déplace la valeur d'un référentiel de règles hors de la documentation : il alimente la couverture de tests et la qualification des signalements, deux activités qui n'ont d'habitude aucune source commune.

Et cela donne une contrepartie immédiate à l'effort d'écriture, ce qui compte pour un travail dont l'exploitation n'a pas commencé : la règle écrite sert dès qu'elle est écrite.

Nuances et limites

Une règle qui vaut comme test doit être vraie sans condition tacite. « Certaines opérations exigent une validation » n'est pas un test : c'est une règle écrite en général là où le cas attendait le détail, et c'est le défaut le plus fréquent et le plus difficile à voir dans ce genre de corpus.

Un objet décrit sans aucune règle ne signale jamais un métier sans règles : il signale une description superficielle.

Questions ouvertes

• Quelle part des règles ainsi écrites survit au passage en test automatisé sans qu'il faille les réécrire dans un vocabulaire technique ?