Tests d'intégration et d'acceptation : cahier de recette et PV

Un test d'intégration vérifie que les composants d'un service fonctionnent ensemble : l'application avec sa base, avec l'annuaire, avec le relais de courriel, le poste avec le serveur à travers le pare-feu. Un test d'acceptation, qu'on appelle en France la recette, vérifie que le service répond au besoin des utilisateurs : il est mené par eux, à partir d'un cahier de recette, et se conclut par un procès-verbal qui accepte ou refuse la livraison. Ce chapitre organise les deux, puis le suivi des anomalies, la non-régression, le rapport de test et le procès-verbal.

Les niveaux de tests

Un service se teste à plusieurs niveaux, du plus petit morceau au service entier vu par l'utilisateur. Chaque niveau trouve des défauts que les autres ne voient pas.

Les trois premiers niveaux relèvent de la maîtrise d'œuvre : elle les mène avant la recette par les utilisateurs. La recette relève de la maîtrise d'ouvrage : c'est elle qui accepte. Le cours Tests détaille les tests unitaires et automatisés, et le cours Gestion de projet leur place dans le cycle en V.

Les tests d'intégration d'un service

Pour un développeur, un test d'intégration vérifie qu'une route de l'API, son middleware et la base fonctionnent ensemble (tests d'intégration d'API). Pour un service, la notion est plus large : on vérifie chaque liaison de l'architecture, celles du tableau des dépendances et de la matrice des flux du chapitre 2. Une liaison qui n'a pas été testée est une liaison qui lâchera le jour de l'ouverture.

Vérifier chaque liaison : les commandes utiles

Ces commandes de diagnostic prouvent une liaison et laissent une trace que tu peux copier dans ton rapport. Elles ne modifient rien.

Depuis un poste Windows du VLAN 10 :

# I-01 : le nom se résout-il, et vers quelle adresse ?
Resolve-DnsName pretmatos.ad.sorbier.example

# I-02 : le port 443 est-il joignable à travers le pare-feu ?
Test-NetConnection pretmatos.ad.sorbier.example -Port 443

Depuis srv-pretmatos :

# I-06 (préalable) : le compte de service s'authentifie-t-il en LDAPS ? (mot de passe demandé)
ldapwhoami -x -H ldaps://srv-ad.ad.sorbier.example -D "svc-pretmatos@ad.sorbier.example" -W
# Refais-le avec srv-ad2, puis avec ldaps://ad.sorbier.example, le nom que l'application utilise

# I-03 : quel certificat le service présente-t-il, émis par qui, jusqu'à quand ?
openssl s_client -connect pretmatos.ad.sorbier.example:443 \
  -servername pretmatos.ad.sorbier.example </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -enddate

# F5 : le relais de courriel accepte-t-il les connexions sur le port 25 ?
nc -zv 192.168.21.10 25

# I-05 (préalable) : l'API répond-elle et joint-elle sa base ?
curl --fail --silent https://pretmatos.ad.sorbier.example/api/sante

Les tests non fonctionnels

La recette vérifie l'utilité ; les tests non fonctionnels vérifient la garantie (chapitre 1). Ils sont menés par l'équipe technique, souvent avant la recette pour ne pas faire perdre leur temps aux utilisateurs.

La recette, ou test d'acceptation

La recette est la vérification, par la maîtrise d'ouvrage et ses utilisateurs, que le service livré répond au besoin exprimé. En anglais, on parle d'user acceptance testing (UAT). Elle a ses règles :

• elle est menée par les utilisateurs, pas par ceux qui ont construit le service : Nadia et deux salariés référents, Julie et Karim, pour Prêt'Matos ; les développeurs assistent, observent et notent ;
• elle porte sur une version figée, livrée en recette avec un numéro (1.0.0-rc.1) ;
• elle suit un cahier de recette préparé à l'avance, à partir des exigences ou des critères d'acceptation des user stories (user stories et critères d'acceptation) ;
• elle vérifie aussi ce qui doit être refusé : une recette qui ne teste que les cas qui marchent laisse passer les failles de droits ;
• elle se conclut par une décision écrite, le procès-verbal.

Pour un service d'infrastructure, la recette suit la même logique avec d'autres scénarios : « je me connecte au portail avec mon compte Windows et je déclare une panne d'imprimante », « je retrouve mon dossier de service sur le lecteur réseau, et pas celui de la comptabilité ».

Rédiger un cahier de recette

Le cahier de recette liste les cas de test que les utilisateurs vont dérouler. Chaque cas a un identifiant, l'exigence qu'il vérifie, ses préconditions, ses étapes, le résultat attendu, puis, à l'exécution, le résultat obtenu et le statut. Le cahier s'appuie sur un plan de test : périmètre, environnement, jeu de données, critères pour lancer et pour clore la campagne ; le modèle est dans le cours Tests.

Le cahier de Prêt'Matos 1.0, rédigé par Yanis avec Nadia à partir du backlog :

Les règles d'un bon cas de recette :

1. Un cas, une vérification. « Réserver, annuler et exporter » en un seul cas ne dit pas ce qui a échoué.
2. Des préconditions et des données précises : quel compte, quel matériel, quelles dates. Prépare-les dans le jeu de données de recette.
3. Un résultat attendu observable, que deux personnes jugeraient de la même façon : un message exact, un statut, un code d'erreur.
4. Les valeurs limites et les refus : 15 jours acceptés (R-13), 16 refusés (R-03) ; un salarié qui tente une action de la logistique (R-04).
5. La traçabilité : chaque exigence a au moins un cas, et l'on peut remonter de chaque cas à son exigence. Le modèle détaillé, avec le format Étant donné / Quand / Alors, est dans le cours Tests.

Exécuter la recette et suivre les anomalies

Pendant l'exécution, chaque cas reçoit un statut : OK (conforme), KO (écart constaté), bloqué (impossible à dérouler : environnement en panne, donnée manquante), non exécuté. Chaque KO donne une fiche d'anomalie : identifiant, cas concerné, description, étapes pour la reproduire, captures, gravité, auteur, date, statut.

Le premier tour de recette de Prêt'Matos, sur la version 1.0.0-rc.1 :

Une anomalie suit un cycle : ouverte, corrigée par l'équipe, vérifiée par la personne qui l'a trouvée (qui rejoue le cas), puis close. Dans GLPI ou dans les tickets du dépôt Git, chaque anomalie est un ticket, ce qui garde l'historique.

La non-régression

Une régression est une fonction qui marchait et qui ne marche plus après une modification. Corriger A-04 a touché au contrôle des droits : il faut vérifier que la logistique peut toujours enregistrer une sortie (R-06) et un retour (R-07). Le test de non-régression consiste à rejouer, après chaque correction, les cas qui passaient déjà et qui touchent aux mêmes parties du service.

Pour le second tour, sur la version 1.0.0-rc.2 (A-03 et A-04 corrigées, faux serveur de courriel configuré, A-05 reportée), l'équipe rejoue :

• les cas en échec ou bloqués : R-02, R-04, R-08 ;
• les cas de non-régression choisis par Yanis : R-01, R-03 (même écran de réservation que R-02), R-06 et R-07 (mêmes contrôles de droits que R-04).

Les sept cas sont OK. L'équipe garde la liste des cas de non-régression et l'automatise peu à peu dans la CI : à chaque version future, ils seront rejoués sans effort (tests de non-régression).

Le rapport de test

Le rapport de test rend compte d'une campagne : ce qui a été testé, sur quelle version, avec quels résultats, ce qui reste ouvert et ce que l'équipe recommande. C'est un des indicateurs de la compétence évaluée à l'E5 : « un rapport de test est produit ». Une ou deux pages suffisent.

Un bon rapport donne des chiffres et une recommandation, pas seulement « la recette s'est bien passée ». La commission de l'E5 doit pouvoir le lire en deux minutes et savoir ce qui a été vérifié.

Le procès-verbal de recette

Le procès-verbal de recette (PV) est le document, signé par la maîtrise d'ouvrage, qui prononce sa décision sur la livraison. Trois décisions sont possibles :

• réception sans réserve : le service est conforme ;
• réception avec réserves : il est accepté, mais les anomalies listées, non bloquantes, devront être corrigées dans un délai fixé ;
• refus de réception (ou ajournement) : des anomalies bloquantes empêchent l'acceptation ; une nouvelle recette aura lieu après correction.

Procès-verbal de recette — Prêt'Matos, version 1.0.0-rc.2

Recette menée sur l'environnement de recette, selon le cahier de recette version 2, du J−12 au J−10. Rapport de test joint.

Décision : réception avec réserves.

Réserve : anomalie A-05 (format des dates de l'export CSV), mineure, à corriger dans un délai de 15 jours après la mise en production.

La version recettée, 1.0.0-rc.2, sera publiée sans modification sous le numéro 1.0.0.

Fait le J−7. Pour la maîtrise d'ouvrage : Nadia Faure, responsable logistique. Pour la maîtrise d'œuvre : Lina et Yanis.

Le PV a des effets concrets : il autorise la mise en production (c'est un critère du go/no-go), il fixe ce que l'équipe doit encore livrer, et rien de plus, et, avec un prestataire, il déclenche souvent le paiement et le début de la garantie. Le cours Gestion de projet revient sur sa portée contractuelle.

VABF et VSR

Dans les contrats informatiques, en particulier les marchés publics, la recette se fait souvent en deux temps, avec deux sigles que tu rencontreras en stage.

La VSR correspond au suivi du chapitre 7 : on ne prononce la réception définitive qu'après avoir vu le service tenir dans la durée. Les durées et les conditions varient d'un contrat à l'autre : c'est le contrat qui fait foi.

Exercices