Organisation d'une recette

Pré-requis

Planification

La recette, ou plutôt « les recettes » d'un projet de développement informatique doivent faire partie intégrante du projet. Cela signifie notamment que les phases de recette doivent être :

• Estimées : combien de temps nécessaire (élaboration des documents, passation, rapports, etc.) et a fortiori combien d'argent ?
• Planifiées : les tests doivent être prévus dans le planning du projet, comme des phases à part entière.
• Évaluées : quelle est l'efficacité de la recette, au regard de la satisfaction du client, du quota de bugs décelés, etc. ?

Industrialisation

La recette doit être industrialisée, c'est à dire reposer sur des process clairement établis et documentés, et permettre de produire des résultats (rapports de test, création d'entrées dans un outil de ticketting, etc.) à partir d'un ensemble de données en entrée (cas de tests notamment).

Déroulement

Cette section présente un déroulement type pour une recette informatique. Bien entendu, des ajustements sont à apporter en fonction du contexte du projet, mais ces étapes sont relativement génériques et applicables à une grande majorité de projets. Ce processus implémente généralement le concept de la roue de Deming (PDCA) : plan, do, check, act.

1. Préparation et planification

Cette phase de préparation, réalisée très tôt dans le cycle de vie du projet, a pour objectif de poser les bases de la stratégie de test et de s'assurer que toutes les conditions nécessaires à sa réussite sont réunies.

Une des préoccupations principales de cette étape est également de prévoir la voilure qui sera nécessaire, en matière de ressources (humaines et autres), pour l'exécution de la recette fonctionnelle.

On y anticipe notamment la mise à disposition d'un environnement de recette, qui soit pleinement opérationnel et fonctionnel.

2. Alimentation du « cahier de recette »

Le cahier de recette regroupe l'ensemble des tests qui devront être déroulés avant la livraison du produit.

L'alimentation du cahier de recette doit, idéalement, être réalisée au fur et à mesure que les spécifications fonctionnelles sont réalisées. En effet, les cas de test se fondent sur les cas d'utilisation de l'application, et ces cas d'utilisation sont identifiés, formalisés et documentés en phase de spécification fonctionnelle.

Il existe généralement une infinité de test cases pour un use case : il y a ici une notion de retour sur investissement (ROI) à considérer, car si l'exhaustivité est impossible, le sur-dimensionnement d'un projet de recette a un coût parfois injustifié (par exemple, certaines fonctionnalités non critiques n'ont probablement pas besoin d'être validées par des campagnes de test manuel)

Dans certains projets, le cahier de recette est réalisé beaucoup plus tard : c'est généralement une perte de temps et un risque de décalage entre la réalité du système créé et les cas de test identifiés a posteriori.

3. Constitution des jeux d'essai

Pour une recette fonctionnelle optimale, il est important de disposer de données « réelles », c'est à dire représentatives de ce qui sera rencontré en production. Une stratégie souvent utilisée est de « redescendre » des données de production existantes sur les environnements de test, et de les compléter avec les données manquantes (c'est à dire concernant des fonctionnalités nouvelles).

Cette étape n'est pas aussi simple qu'elle n'y parait, et est souvent négligée.

4. Exécution des tests

Quand le cahier de recette est fourni, que l'environnement de test est opérationnel et doté de jeux de données pertinents, et enfin (surtout) que les développement ont été réalisés, les tests fonctionnels peuvent démarrer.

L'exécution des tests est généralement mixte : manuel et automatisé. Les tests manuels sont exécutés par une équipe de recette voire directement par la maîtrise d'ouvrage, et les tests automatisés sont exécutés par des outils dédiés (Squash TA, SilkTest…).

Si des anomalies sont détectées par les tests manuels ou automatisées, elles sont tout d’abord qualifiées (est-ce réellement une anomalie ou simplement une mauvaise utilisation d'une fonctionnalité ?) et, le cas échéant, leur résolution est priorisé et prise en charge par les équipes MOE.

Cette étape est répétée autant que fois que nécessaire.

5. VABF et VSR

Cette étape est géré de façon relativement différente en fonction du contexte du projet, des exigences du client, etc.

En théorie, une fois la recette d’usine (réalisée par le fournisseur du service) terminée et que le produit a été jugé conforme, il est livré au client pour test, sur un environnement dédié. Le client entame alors, généralement, une phase de recette de son côté, avec sa propre méthodologie.

Quand le client estime que le produit a atteint un niveau de conformité suffisant, il prononce la VABF (vérification d'aptitude au bon fonctionnement), qui permet de déployer le système sur une unité pilote de production. De nouvelles anomalies y sont généralement détectées, faisant l'objet d'un « Early Life Support Plan »

Enfin, quand toutes les corrections nécessaires ont été apportées, le client prononce la VSR (vérification de service régulier), qui autorise la mise en exploitation globale de la solution. Le projet est alors terminé.

Livres intéressants

Lessons Learned in Software Testing: A Context–Driven Approach

Voir