Cahier de recette : relier le test à la règle métier
Le cahier de recette modèle proposé ci-dessous sert à préparer les essais d’une application qui remplace Access ou Excel, ou qui modernise une interface SQL Server. Pour chaque cas, le testeur doit retrouver l’acteur, les données de départ, les actions et le résultat attendu. Le résultat observé est saisi après l’exécution. Ne préremplissez pas une validation avant les essais.
Le processus de recette de l’application organise les rôles et les décisions. Le cahier est le support qui conserve les preuves de cette exécution. Microsoft décrit dans sa documentation des tests d’acceptation utilisateur l’affectation des tests aux personnes et le suivi de leurs résultats.
- Une règle métier identifiée pour chaque cas.
- Un résultat attendu assez précis pour décider.
- Un résultat observé et une preuve conservée.
Les colonnes de la trame
| Champ | Contenu à renseigner |
|---|---|
| Identifiant et exigence | Référence stable du test et de la règle concernée. |
| Préconditions | Profil, statut du dossier et configuration nécessaires. |
| Données de test | Jeu d’essai repérable et protégé. |
| Étapes | Actions à exécuter dans l’ordre. |
| Attendu et observé | Critère prévu puis résultat constaté. |
| Anomalie et preuve | Référence du défaut, capture ou état de contrôle. |
| Décision | Statut du test, responsable et vérification après correction. |
Les spécifications fonctionnelles donnent les règles à vérifier. Si elles changent pendant le projet, rattachez chaque exécution à la bonne version. Une ligne marquée « conforme » sans version ni contexte ne permet pas de comprendre ce qui a été validé.
Couvrir les parcours ordinaires et les refus
Pour une validation de devis, essayez le parcours autorisé puis le refus par un profil non habilité. Vérifiez aussi ce qui se passe si une donnée requise manque ou si le dossier a changé entre son ouverture et sa validation. Dans votre contexte, choisissez les cas avec le responsable du processus : leur pertinence compte davantage qu’une longue liste sans lien avec les règles.
- Préparer le jeu d’essai et les accès des testeurs.
- Exécuter chaque cas et consigner l’observation.
- Qualifier l’impact des anomalies sur l’activité.
- Rejouer le cas corrigé et les parcours qui en dépendent.
Pour la migration de la base de données, ajoutez les rapprochements de comptages, relations et états métier. Un total identique ne prouve pas l’absence de toute erreur. Définissez aussi les détails et liens à contrôler.
Décider de la réception et protéger les essais
Avant l’exécution, faites définir les anomalies qui empêchent la réception et celles qui peuvent donner lieu à une réserve acceptée. La décision finale indique les cas non testés et leurs motifs. Elle doit être comprise par les responsables de l’activité, puis reliée au plan de migration et de bascule.
Questions pratiques
Qui remplit le cahier de recette ?
Le responsable de recette prépare le support avec les utilisateurs et l’équipe technique. Les personnes qui exécutent les tests y consignent leurs observations ; les responsables désignés prennent la décision de réception.
Quelle différence avec un plan de test ?
Le plan définit le périmètre, les moyens et l’organisation des essais. Le cahier détaille les cas et conserve leurs résultats. Vous pouvez regrouper ces rubriques dans un même document si les rôles et les versions restent lisibles.
Sources officielles
Références vérifiées le 20 octobre 2026. Les grilles proposées servent à préparer le projet avec vos responsables métier et techniques.