Un cahier de recette est un des livrables majeurs d’un business analyst sur un projet. C’est un livrable engageant quant à la qualité de ce qui sera livré effectivement et un acte de communication qui attirera l’attention des leaders et sponsors du projet. Trop souvent, le travail effectué l’est avec sérieux mais n’est pas assez formalisé. Cela a pour conséquence principale que le résultat des tests communiqué est déclaratif. Dans les faits, le cahier de recette communique un status mais permet pas de savoir si les tests sont pertinents et encore moins de savoir s’ils ont été correctement exécutés.

Un cahier de recette de qualité doit respecter les 7 axes ci-dessous :

1. Be explicit on the tests conditions

  • Un cahier de recette doit permettre d’identifier les conditions dans lesquelles les tests ont été effectués, on devra retrouver les informations suivantes :
    • Date des runs de tests
    • Description de l’environnement (identifiant du serveur, identifiant de la base de données …)
    • Version des binaires
    • Version des données

Version des spécifications correspondantes

2. Give a Clear test status and an highlighted executive summary

  • Un cahier de recette doit permettre de donner un status synthétique global clair au lecteur en donnant le bon niveau d’alerte au management mais également permettre d’aller du global vers l’analyse unitaire des tests.

3. Be focused on the facts

  • On doit retrouver les éléments :
    • permettant d’identifier le test de manière unique sur l’environnement (trade id…)
    • permettant d’identifier le point de spécification testé
    • prouvant les inputs, les paramétrages & les éléments contrôlés dans le test (screenshots, extractions)

4. Compare results to expected results

  • La stratégie de test a dû être pensée en amont du projet, et l’objectif du cahier de recette étant de vérifier que les points de spécification ont été correctement développés, chaque test doit avoir un expected result connu.

5. Share transparent results

  • Le résultat du cahier de test doit être partagé avec les acteurs du projet, que le résultat soit positif ou pas. Le fait de partager le résultat permet de partager le risque et permet au management de mener les actions adéquates s’ils ont le bon niveau d’information.

6. Give explicit and factorized tests scenarii

  • Le scénario de chaque test doit être explicite de manière à ce que les tests puissent être repris ou suivi par toute personne impliquée dans le projet
  • La factorisation permet de réduire le nombre de tests à jouer et de considérer qu’un test ou plusieurs valident un élément plus large. Cela permet donner une vision transverse au jeu de test.

7. Give Rerunable test cases

  • Un jeu de test doit être pouvoir être rejouer dans les mêmes conditions (pour vérifier qu’on obtient bien les mêmes résultats) ou dans d’autres (pour pouvoir analyser le delta entre deux runs de tests).

Cette méthodologie implique certes un certain formalisme mais elle permet aussi de pouvoir rationnaliser ses tests et de pouvoir automatiser une partie de ses tests de non régression.
In fine, le coût d’une lourde campagne de non régression finit par devenir un cout d’entretien de jeu de tests (plus léger), la couverture de test ne peut être que meilleur et il est plus aisé de comparer objectivement le résultat de deux runs de tests.
Dans les tests, il faut partir du postulat que tout ce qui n’est pas testé ne marche pas.
La rationalisation de la méthodologie de test aura un impact qualitatif réel sur les livrables.
Le sérieux apporté dans la rigueur autour de la communication autour du cahier de recette aura également un impact très positif sur la perception qualitative du travail du business analyst.