À quoi sert vraiment un cahier de recette
Il sert à rendre la recette objective. Tant que les tests vivent dans la tête des gens, chacun vérifie ce qu'il pense important et oublie le reste ; et à la fin, impossible de dire si le site est conforme ou pas. Le cahier de recette fige la liste des cas avant de tester, donc on sait exactement ce qui a été vérifié, par qui, et avec quel résultat. C'est aussi une protection contractuelle : il matérialise ce qui avait été commandé, ligne par ligne, et sert de base au PV de recette à la fin.
La structure minimale d'un cas de test
Un bon cas de test tient en quelques colonnes : un identifiant, la fonctionnalité concernée, le scénario (les étapes à suivre), la donnée d'entrée si besoin, le résultat attendu, puis le résultat obtenu et un statut OK/KO rempli pendant la recette. Le résultat attendu est la colonne qui fait tout : sans elle, le testeur ne sait pas si ce qu'il voit est un bug ou le comportement prévu. Écris-le au présent et de façon vérifiable : "le formulaire affiche un message de confirmation et envoie un email à l'adresse saisie", pas "le formulaire marche".
Comment organiser le cahier pour un site web
Regroupe les cas par zone, ça évite les trous et ça rend la relecture rapide. Une organisation qui marche : navigation et liens, formulaires et envois, contenus et médias, affichage responsive, compatibilité navigateurs, performance, SEO technique, accessibilité, conformité RGPD. Chaque zone reçoit ses propres cas. Cette structure recoupe directement notre modèle prêt à copier : le cahier de recette n'est qu'une checklist rendue traçable, avec une colonne de statut et un responsable.
Exemple concret de cahier de recette
Prenons le formulaire de contact d'un site vitrine. Cas REC-012 : envoi d'un message valide. Scénario : remplir nom, email, message avec des données correctes, cliquer Envoyer. Donnée d'entrée : email valide format [email protected]. Résultat attendu : un message de confirmation s'affiche, l'email arrive bien dans la boîte de réception cible, le champ se vide. Cas REC-013 : email invalide. Scénario : saisir "abc" dans le champ email, envoyer. Résultat attendu : un message d'erreur clair sous le champ, aucun envoi. Deux lignes, deux résultats nets : tu vois immédiatement à quoi ressemble un cahier exploitable.
Le cahier ne remplace pas le suivi des anomalies
Erreur fréquente : croire que le cahier de recette suffit à tout. Il liste ce qu'on vérifie et le statut OK/KO, mais un KO n'est pas encore un ticket corrigeable. Quand un cas échoue, il faut ouvrir une anomalie avec son contexte (URL, navigateur, capture, étapes), la prioriser, la suivre jusqu'au correctif, puis revérifier la ligne du cahier. Le cahier dit "quoi tester" ; un tableau de tickets dit "où en est chaque bug". Les deux travaillent ensemble : le widget Couac transforme un KO en ticket reproductible sans ressaisie.
Questions fréquentes
Cahier de recette ou plan de test, quelle différence ?
Le plan de test est plus large : il décrit la stratégie de test (quoi tester, comment, avec quels moyens, sur quel périmètre). Le cahier de recette est l'exécution concrète côté validation : la liste des cas réellement passés pour accepter le livrable, avec leur résultat. En pratique, sur un projet web, le cahier de recette est souvent le seul document formel, et il joue les deux rôles.
Sous quel format faire un cahier de recette ?
Un tableur suffit pour démarrer : une ligne par cas, des colonnes scénario / résultat attendu / résultat obtenu / statut. Excel ou Google Sheets font le travail pour un site vitrine. Le format compte moins que la discipline : cas écrits avant de tester, résultat attendu vérifiable, statut tenu à jour. Dès que le volume d'anomalies grimpe, double le cahier d'un outil de suivi de tickets pour ne pas gérer les bugs dans la même feuille.
Qui rédige le cahier de recette ?
En général le chef de projet ou un référent qualité côté prestataire, à partir du cahier des charges. L'idéal est de le faire valider par le client avant la recette : ainsi, la liste des cas reflète ce que lui attend, pas seulement ce que l'équipe a en tête. Sur les projets agiles, ce sont souvent les critères d'acceptation de chaque user story qui alimentent le cahier au fil de l'eau.
Qui réalise la recette, et avec quel cahier ?
Côté prestataire, l'équipe passe d'abord une recette interne à partir du cahier ; côté client, un référent métier déroule les mêmes cas pour valider la conformité au besoin. Le testeur n'a pas besoin d'être technique : un cahier de recette bien écrit, avec un résultat attendu clair par cas, permet à n'importe quel relecteur de trancher OK ou KO sans connaître le code. C'est tout l'intérêt d'un résultat attendu vérifiable plutôt que d'un vague "vérifier que ça marche" : la recette ne dépend plus de qui tient le clavier.