Plan de tests et cahier de recette
La stratégie de test et les cas exécutés : ce qui est testé, par qui, sur quelles données, et ce qui autorise la mise en production.
8 rubriques, consignes de rédaction incluses. Sans inscription. Le tableur contient une grille « Cas de test » prête à remplir.
À quoi sert ce document
Le plan de tests dit ce qu'on va vérifier et pourquoi ce niveau de vérification suffit. Le cahier de recette porte les cas eux-mêmes, exécutables par quelqu'un qui n'a pas écrit la spécification. Ensemble, ils rendent le passage en production décidable sur des faits plutôt que sur un sentiment : les critères de sortie sont posés à l'avance, pas négociés le jour du comité, lorsque la pression de calendrier rend toute anomalie soudainement mineure.
Quand le produire
- Sur tout projet dont la mise en production suit une décision formelle de go / no-go.
- Quand la recette est confiée à des utilisateurs métier qui n'ont pas suivi la conception.
- Sur une migration ou une reprise de données, où la vérification porte sur des volumes et non sur des écrans.
- Quand la réception conditionne un paiement ou le démarrage d'une garantie.
Référentiel de rattachement : ISO/IEC/IEEE 29119 (test logiciel)
La norme sépare la stratégie de test (les niveaux, les critères d'entrée et de sortie, les risques couverts) de la conception des cas de test. Le plan ci-dessous suit cette séparation, en un seul document pour les projets de taille moyenne.
Le plan, rubrique par rubrique
-
Périmètre de la recette
Ce qui est testé et ce qui ne le sera pas, avec le risque assumé.
- Fonctions, flux et interfaces couverts
- Exclusions explicites et justification du risque accepté
- Versions et lots concernés
-
Niveaux et types de tests
Qui teste quoi, à quel niveau, pour ne pas tester deux fois la même chose.
- Tests unitaires et d'intégration : périmètre MOE
- Recette fonctionnelle : périmètre MOA
- Tests de bout en bout sur les processus complets
- Tests de performance et de charge, avec le profil de charge cible
- Tests de sécurité et de gestion des habilitations
- Tests de non-régression, et périmètre rejoué à chaque livraison
- Recette technique : exploitation, reprise sur incident, retour arrière
-
Environnements et jeux de données
Le point qui fait glisser la plupart des plannings de recette.
- Environnements utilisés et leur représentativité par rapport à la production
- Origine des jeux de données et anonymisation des données personnelles
- Volumétrie utilisée pour les tests de performance
- Procédure de réinitialisation entre deux campagnes
-
Organisation
Qui fait quoi, quand, avec quel outillage.
- Recetteurs désignés par domaine, et charge prévue par personne
- Calendrier des campagnes et des livraisons
- Outil de suivi des anomalies et circuit de qualification
-
Cas de test
Le cœur du cahier de recette. Un cas doit être rejouable par un tiers.
- Identifiant, exigence ou BUC couvert
- Préconditions et jeu de données de départ
- Étapes d'exécution numérotées
- Résultat attendu, formulé sans ambiguïté
- Résultat obtenu, statut, date, exécutant
-
Matrice de couverture
La preuve que le périmètre contractuel est testé.
- Tableau exigence -> cas de test -> statut
- Exigences non couvertes et décision associée
-
Gestion des anomalies
La classification décidée avant la campagne, pas pendant.
- Grille de sévérité : bloquante, majeure, mineure, cosmétique, avec définition de chacune
- Circuit : déclaration, qualification, correction, retest, clôture
- Délais de traitement attendus par niveau de sévérité
-
Critères de sortie
La règle chiffrée qui autorise la mise en production.
- Taux d'exécution et taux de réussite minimum exigés
- Aucune anomalie bloquante ouverte, seuil toléré pour les majeures
- Anomalies restantes avec contournement documenté et échéance de correction
Les erreurs qui coûtent cher
- Écrire des résultats attendus flous. « Le résultat est correct » n'est pas vérifiable par un tiers, et n'est donc pas un test.
- Découvrir les jeux de données en début de campagne. La préparation des données est la première cause de retard en recette, et elle se prépare en amont.
- Négocier les critères de sortie le jour du comité de mise en production. Posés avant, ils protègent la décision ; posés après, ils la justifient.
- Ne pas tester les cas d'erreur ni les reprises sur incident. La production les testera à votre place, avec des utilisateurs réels.
- Recetter sur des volumes de démonstration. Un traitement validé sur 500 lignes ne dit rien de son comportement sur 5 millions.
Sigles associés
Documents complémentaires
Besoin d'un cadrage, pas seulement d'un modèle ?
Nous rédigeons et challengeons ces documents en mission, sur des projets d'intégration, de migration de données et de décisionnel. Parlons de votre projet.