Plan de test, cahier de recette et rapport de test

Le plan de test décrit comment une version sera testée : périmètre, types de tests, environnements, données, critères pour commencer et pour terminer. Le cahier de recette liste les cas de test qui vérifient chaque exigence, avec leurs étapes et leur résultat attendu. Le rapport de test rend compte de la campagne : ce qui a été testé, ce qui passe, ce qui échoue, et la recommandation de mise en production ou non. Ces trois documents sont des livrables attendus à l'E5 (« un rapport de test est produit ») et souvent à l'E6. Ce chapitre les rédige pour une évolution de Prêt'Matos.

Les documents du test

Le cours Gestion de projet décrit la place de la recette dans le projet, le cycle des anomalies et le procès-verbal (recette et clôture). Ce chapitre se concentre sur la rédaction des documents de test.

L'évolution à recetter

Nadia a validé une nouvelle user story pour la version 1.5 de Prêt'Matos :

En tant que salarié, je veux prolonger mon prêt en cours afin de garder le matériel quand ma mission dure plus longtemps que prévu.

Critères d'acceptation :

• la prolongation dure de 1 à 7 jours ;
• la durée totale du prêt, prolongation comprise, ne dépasse pas 15 jours ;
• on ne peut pas prolonger un prêt déjà en retard ;
• on ne peut pas prolonger si le matériel est réservé par quelqu'un d'autre sur la période ajoutée ;
• seul l'emprunteur peut prolonger son prêt ;
• après la prolongation, la nouvelle date de retour s'affiche et le rappel part la veille de cette nouvelle date.

Le plan de test

Un plan de test n'a pas besoin d'être long. Pour une version d'une application interne, une ou deux pages suffisent, organisées en rubriques fixes.

Les critères d'entrée évitent de commencer une recette sur une version qui ne démarre pas ; les critères de sortie disent à l'avance ce qui permettra de dire « c'est fini ». Sans eux, la recette s'arrête quand on n'a plus le temps, et la décision de livrer se prend à l'intuition.

Des critères d'acceptation aux cas de test

Chaque critère d'acceptation donne au moins un cas de test, souvent deux ou trois : le cas qui passe, et les valeurs limites qui doivent être refusées ou acceptées (chapitre 3). Le format Étant donné / Quand / Alors aide à les écrire sans ambiguïté :

# language: fr
Fonctionnalité: Prolonger un prêt

  Scénario: La prolongation porte le prêt à 15 jours tout juste
    Étant donné que Julie a emprunté PC-07 du 10 au 19 mars, soit 10 jours
    Et que PC-07 n'est réservé par personne après le 19 mars
    Quand Julie prolonge son prêt de 5 jours le 15 mars
    Alors la prolongation est acceptée
    Et la nouvelle date de retour affichée est le 24 mars

  Scénario: La prolongation dépasserait 15 jours
    Étant donné que Julie a emprunté PC-07 du 10 au 19 mars, soit 10 jours
    Quand Julie prolonge son prêt de 6 jours le 15 mars
    Alors la prolongation est refusée
    Et le message « Un prêt dure au plus 15 jours. » s'affiche

Rédiger un bon cas de test

Un cas de test doit pouvoir être exécuté par quelqu'un d'autre que son auteur, sans lui poser de question, et donner le même verdict. Il contient :

Le lien entre chaque exigence et ses cas de test s'appelle la traçabilité. À la fin de la rédaction, aucune exigence ne doit rester sans cas, et aucun cas sans exigence.

Le cahier de recette de la prolongation

Remarque les cas R-PROL-02 et R-PROL-03 (7 et 8 jours), puis R-PROL-04 et R-PROL-05 (15 et 16 jours au total) : les valeurs limites de chaque règle. Le cas R-PROL-08 est un test de sécurité ; il se fait en appelant l'API directement, parce que l'écran ne montre jamais le bouton à quelqu'un d'autre que l'emprunteur. Une recette ne vérifie pas seulement que ce qui doit marcher marche, mais aussi que ce qui doit être refusé l'est.

Exécuter la campagne et suivre les anomalies

Pendant la campagne, chaque cas reçoit un statut :

La fiche d'anomalie A-21 de R-PROL-05 contiendrait : l'identifiant, le cas de test, la version (1.5.0-rc.1), la description (« une prolongation qui porte le prêt à 16 jours est acceptée »), les étapes pour reproduire, le résultat attendu et le résultat obtenu, une capture, la gravité, l'auteur et la date. Sa gravité décide de la suite : bloquante, majeure ou mineure (les anomalies). Ici, une règle métier n'est pas appliquée : c'est une anomalie majeure.

Quand l'anomalie est corrigée, deux choses se passent : on rejoue le cas qui avait échoué (R-PROL-05), puis on rejoue la non-régression, car la correction a pu casser autre chose (chapitre 11). Côté développeur, la correction arrive avec un test automatisé qui reproduit A-21 : la même anomalie ne pourra pas revenir.

Le rapport de test

Le rapport de test (on dit aussi bilan de campagne) se lit en deux minutes par quelqu'un qui doit décider. Il commence par la conclusion et les chiffres, puis donne le détail.

Rapport de test — Prêt'Matos 1.5.0-rc.1 — Prolongation de prêt

Contexte. Recette de la story n° 12 « prolonger un prêt » et non-régression de la version 1.5, du 29 au 31 mars, sur l'environnement de recette. Testeurs : Nadia Faure (logistique), Julie Lefèvre et Karim Morel (salariés). Rédaction : Lina.

Conclusion. Mise en production non recommandée en l'état : une anomalie majeure (A-21) est ouverte. Après sa correction et un nouveau passage des cas R-PROL-05 et de la non-régression, la mise en production peut être envisagée le 5 avril comme prévu.

Synthèse des tests manuels.

Ensemble	Cas	OK	KO	Bloqués
Prolongation (R-PROL-01 à 09)	9	7	1	1
Non-régression (NR-01 à NR-06)	6	6	0	0
Total	15	13	1	1

Tests automatisés. 82 tests unitaires et d'intégration, tous verts dans la CI sur la version testée ; couverture des lignes de 91 %. 3 tests de bout en bout verts.

Anomalies. A-21, majeure, ouverte : une prolongation qui porte le prêt à 16 jours est acceptée (R-PROL-05).

Points non vérifiés. R-PROL-09 bloqué : l'envoi des courriels est désactivé sur l'environnement de recette. La date de rappel est couverte par un test automatisé ; une vérification réelle est proposée en production sur un prêt de test, le jour de la mise en service.

Couverture des exigences. Les 6 critères d'acceptation ont au moins un cas exécuté ; 4 sont validés, 1 est en anomalie (total de 15 jours) et 1 n'est vérifié qu'en partie (la nouvelle date s'affiche, mais le rappel n'a pas pu être contrôlé : R-PROL-09 bloqué).

Les chiffres du rapport doivent être cohérents : 13 OK + 1 KO + 1 bloqué = 15 cas. Un rapport qui ne cite que les succès n'est pas un rapport, c'est une publicité : la commission comme le client attendent de voir ce qui ne marche pas et ce que tu proposes.

La recette avec les utilisateurs

Le test d'acceptation par les utilisateurs vérifie ce qu'aucun test automatisé ne vérifie : l'application convient-elle à ceux qui s'en servent ? Quelques règles pour une séance utile :

• choisir des utilisateurs clés qui représentent les rôles (un salarié, une personne de la logistique), et pas seulement le Product Owner ;
• leur donner des scénarios métier (« vous partez en mission trois jours de plus que prévu »), pas les étapes techniques du cahier : on observe s'ils trouvent seuls ;
• observer sans aider et noter les hésitations : un utilisateur qui cherche le bouton pendant une minute est une information ;
• distinguer, dans les retours, les anomalies (l'application ne fait pas ce qui était convenu) des demandes d'évolution (elle fait ce qui était convenu, mais l'utilisateur voudrait autre chose). Les premières se corrigent, les secondes vont au backlog ;
• conclure par une décision écrite : le procès-verbal de recette, signé par la MOA.

Ce qu'on attend de toi à l'E5 et à l'E6

À l'E5 (bloc 1, commun aux deux options), la compétence « mettre à disposition des utilisateurs un service informatique » demande de réaliser les tests d'intégration et d'acceptation d'un service. La commission vérifie que des tests pertinents sont rédigés et effectués, que les outils de test sont utilisés correctement et qu'un rapport de test est produit (les compétences du bloc 1). Pour une réalisation de ton portfolio, garde donc : le cahier de recette avec les résultats, les fiches d'anomalies, le rapport de test, et les traces de l'exécution (captures, journal de la CI).

À l'E6 SLAM, la fiche descriptive de chaque réalisation cite tes outils de test, et l'expression des besoins remise par la commission peut demander, comme documentation à présenter, un rapport de test (le modèle de l'expression des besoins). Pendant l'heure de réalisation, il ne s'agit pas d'écrire dix pages : un rapport court et honnête suffit, préparé à l'avance sous forme de modèle.

RAPPORT DE TEST — [réalisation] — [évolution demandée]
Date, version (commit), environnement : poste local, base de test

1. Ce qui a été testé
   - tests automatisés ajoutés : [noms des tests] → résultat de `npm test` (capture)
   - tests manuels : cas nominal, cas refusés (tableau : cas, attendu, obtenu, statut)

2. Résultat
   - X tests automatisés, tous verts / Y en échec (lesquels, pourquoi)
   - non-régression : suite complète relancée, verte

3. Ce qui n'a pas été testé, et pourquoi

4. Anomalies ou limites connues, et ce que je ferais ensuite

Pendant la recette de l'E6, montre le terminal avec la suite verte, puis le rapport : c'est la preuve des compétences « réaliser les tests nécessaires à la validation » et « élaborer et réaliser les tests des éléments mis à jour » (la recette de l'E6).

Exercices

RAPPORT DE TEST — Prêt'Matos — Export CSV de l'historique des prêts
Date : jour de l'épreuve. Version : commit a1b2c3d. Environnement : poste local, base de test.

1. Ce qui a été testé
   Tests automatisés ajoutés (Vitest + Supertest), dans src/export.test.js :
   - « exporte l'historique de la période pour la logistique » : 200, en-tête CSV + 2 lignes
   - « refuse l'export à un salarié » : 403
   - « refuse une période mal formée » : 400
   Test manuel : fichier ouvert dans le tableur, colonnes séparées, accents corrects.

2. Résultat
   47 tests automatisés, tous verts (capture de npm test), dont les 3 nouveaux.
   Non-régression : suite complète relancée après l'évolution, verte.

3. Non testé
   Un nom ou un libellé contenant un point-virgule ou un guillemet.

4. Limites et suite
   Risque : un point-virgule dans un libellé décalerait les colonnes. Correction prévue :
   mettre ces champs entre guillemets en doublant les guillemets internes, avec un test dédié.