Créer une checklist de recette à partir d’une démonstration enregistrée
Transformez la démonstration en checklist de recette avec conditions, actions, résultats attendus et preuves. Un exemple fondé sur les exigences convenues.
Une démonstration réussie couvre les scénarios qu’elle montre
Pendant l’appel, le formulaire semblait transmettre la demande correctement. Un autre rôle, un second envoi ou un champ obligatoire vide ont pu être omis. L’enregistrement conserve la démonstration. Les autres cas restent à tester.
La checklist repose sur des exigences convenues à l’avance. Une idée nouvelle du public peut être utile, mais consignez-la séparément. Si le périmètre change en cours de recette, les participants finissent par parler de tâches différentes.
Préparer les contrôles à partir de l’enregistrement
Notez la version et les conditions
Indiquez la version ou le build, la personne qui a fait la démonstration et le rôle utilisé. Décrivez les données de test et l’environnement de façon à permettre une répétition. Signalez les conditions inconnues.
Reliez le contrôle à une exigence
Retrouvez dans l’enregistrement le comportement convenu. Une démonstration peut couvrir plusieurs contrôles, mais chacun a besoin d’un résultat attendu distinct. Marquez « non testé » toute exigence obligatoire absente de la démonstration.
Décrivez l’action et le résultat attendu
Au lieu de « vérifier le formulaire », précisez les données à saisir, la commande à cliquer et le résultat attendu. Décrivez la réaction à une saisie invalide. Un cas limite nouveau n’entre dans la recette que si le périmètre le prévoit.
Rejouez les contrôles
Exécutez les scénarios sur la version convenue, consignez le résultat réel et joignez la preuve. Distinguez les échecs, les tests bloqués et les données manquantes. Après correction, rejouez le scénario et notez la nouvelle date.
Recette d’un formulaire de demande de consultation
Cet exemple est fictif. Les noms, conditions et résultats servent à expliquer la méthode.
Le téléphone est obligatoire. Après un envoi réussi, la demande apparaît dans la liste et le visiteur voit une confirmation. Sans téléphone, l’envoi doit être refusé.
Il y a trois résultats observables : validation du champ, création de la demande et confirmation au visiteur. Un écran soigné après le clic ne prouve qu’une partie du résultat.
Si le testeur n’a pas accès à la liste, marquez la création comme « bloquée ». La parole du présentateur ne suffit pas à la déclarer réussie.
| Vérification | Résultat attendu | Preuve à conserver |
|---|---|---|
| Téléphone vide | Message de champ obligatoire et aucune demande créée | Capture et contrôle de la liste |
| Données valides | Une demande avec les valeurs saisies | Entrée dans la liste de test |
| Envoi réussi | Confirmation claire au visiteur | Capture après l’action |
Modèle d’un point de recette
Chaque ligne indique l’observation qui détermine le statut final.
Identifiant du contrôle : Exigence convenue : Version / rôle / environnement : Données d’entrée : Actions : Résultat attendu : Résultat réel : Statut : réussi / échec / non testé / bloqué Preuve et repère temporel : Correction associée : Date du nouveau contrôle :
Vérifiez la checklist avant de commencer
- Les points renvoient au périmètre convenu.
- Le résultat attendu est visible ou mesurable.
- Les éléments montrés et les tests reproduits sont distingués.
- Les conditions des échecs sont reproductibles.
Dans le détail
Faut-il ajouter toutes les remarques de la réunion ?
Distinguez les défauts au regard des exigences et les demandes nouvelles. Évaluez et validez les nouvelles demandes à part pour éviter d’élargir continuellement le projet.
Peut-on accepter le résultat sur la seule vidéo ?
Cela dépend des règles de recette. La vidéo atteste ce qu’elle montre. Indiquez la méthode et les limites du contrôle dans le document.