Définition
Le cahier de recette est le document qui liste les cas de test à dérouler pour vérifier qu'un site ou une application est conforme au besoin exprimé. Chaque ligne décrit une situation à tester, les étapes à suivre et le résultat attendu, puis laisse la place au résultat obtenu et au verdict. Il sert de support à la campagne de recette et de preuve de ce qui a été contrôlé.
Modèle offert
Téléchargez le cahier de recette
Le tableur que j'utilise en mission : trois onglets (mode d'emploi, cas de test, synthèse), les statuts et criticités déjà paramétrés, cinq exemples de cas de test pour démarrer. Libre d'usage, sans inscription.
On le trouve aussi sous le nom de cahier de recettage ou de plan de tests. Peu importe l'intitulé : ce qui compte est qu'il existe avant la livraison, et qu'il soit écrit par le côté client, pas par celui qui a développé.
À quoi il sert vraiment
Sans ce document, la recette se résume à une impression générale, et une impression ne se défend pas en réunion.
- Rendre la vérification exhaustive. Les fonctions rarement utilisées sont celles que personne ne pense à ouvrir, et celles qui cassent en silence pendant des mois.
- Répartir le travail. Chaque testeur reçoit un périmètre nommé, ce qui évite que trois personnes testent la même page d'accueil et que personne n'ouvre l'espace client.
- Objectiver le désaccord. Face à un prestataire qui estime la livraison conforme, une ligne « résultat attendu » issue du cahier des charges met fin au débat.
- Servir de mémoire. Il resservira à la version suivante, et à chaque mise à jour lourde du produit.
Ce qu'il contient
Un cahier de recette est un tableau, tenu dans un tableur ou dans l'outil de suivi du projet. Les colonnes que j'utilise sont toujours les mêmes.
| Colonne | Ce qu'on y écrit |
|---|---|
| Identifiant | Un code court et stable, pour parler du cas sans le décrire (par exemple CMD-04). |
| Périmètre | La fonction concernée : compte client, recherche, tunnel de commande, formulaire de contact. |
| Prérequis | L'état de départ : utilisateur connecté, panier vide, navigateur mobile. |
| Étapes | Les actions à effectuer, dans l'ordre, assez précises pour qu'un autre testeur obtienne le même résultat. |
| Résultat attendu | Ce qui doit se produire, en une phrase vérifiable. C'est la colonne qui vient du cahier des charges. |
| Résultat obtenu | Ce qui s'est réellement passé, décrit et non résumé en « ne marche pas ». |
| Verdict et sévérité | Conforme, non conforme, et le niveau de gravité qui décide si le défaut bloque la mise en ligne. |
| Testeur et date | Qui a joué le cas, sur quelle version. Sans cela, un retest ne veut rien dire. |
J'y ajoute toujours un onglet de contrôles transverses, ceux qui ne se rattachent à aucune fonction précise : affichage sur mobile, comportement sur les principaux navigateurs, balises de référencement, et l'échantillon d'anciennes URL à vérifier quand la refonte s'accompagne d'un plan de redirection 301.
Comment je le construis
Le cahier de recette ne s'invente pas à la livraison. Il se déduit, ligne à ligne, de ce qui a été commandé. Je repars du volet fonctionnel du cahier des charges : chaque exigence donne au moins un cas de test, et les exigences qui n'en donnent aucun sont en général celles qui étaient trop vagues pour être développées correctement. Quand le projet est mené en agile, le travail est déjà à moitié fait : les critères d'acceptation des user stories deviennent les résultats attendus.
J'écris aussi des cas d'erreur, pas seulement des parcours nominaux : champ obligatoire laissé vide, adresse mal formée, paiement refusé, fichier trop lourd. Un produit se casse presque toujours sur ce que ses concepteurs n'avaient pas prévu qu'un utilisateur ferait.
Les erreurs fréquentes
- Le faire écrire par le prestataire. Il testera ce qu'il a construit, dans l'ordre où il l'a construit, et pas ce que vous attendiez.
- Confondre exigence et cas de test. « Le site doit être ergonomique » ne se teste pas. « Le menu reste accessible après défilement sur un écran de 375 pixels » se teste.
- L'abandonner après la première passe. Le cahier sert à chaque retest, et c'est lui qui montre qu'une correction en a cassé une autre.
La démarche complète, du gel de la préproduction au procès-verbal, est décrite dans ma fiche sur le recettage et dans mon guide sur la recette d'une refonte.
Questions fréquentes
À propos de l'auteur
Laurent Tulpan
Directeur de projet digital senior, ancien développeur et expert SEO depuis 2005. Il construit les cahiers de recette de ses clients à partir de leur cahier des charges, et fait tenir la campagne jusqu'au procès-verbal. Découvrir son approche.
À lire ensuite
Le recettage
La phase de vérification que ce cahier vient outiller.
La recette d'une refonte de site web
Les familles de tests à couvrir et l'organisation d'une campagne.
Cahier des charges fonctionnel ou technique
D'où viennent les exigences que le cahier de recette vérifie.
La user story
Les critères d'acceptation, matière première des cas de test.