Organiser une recette

a. Quand ?

Comme le titre de cette section le laisse entendre, le projet est en feu ce qui signifie que la situation est extrêmement préoccupante.

Généralement, celle-ci s’observe lorsque la ou les recettes n’ont pas été anticipées et que les premiers tests révèlent une application hautement instable avec un taux d’anomalie très élevé.

Notamment, les anomalies bloquantes feront que le périmètre des tests effectivement jouables est si faible que le lancement de la recette doit être annulé au profit d’une autre action : la recette "pompier".

En toute logique, cette situation s’observe principalement dans un chantier de release bien que le chantier de maintenance puisse connaître des situations plus ou moins similaires selon la taille des évolutions mises en œuvre ou le contexte du projet.

b. Pourquoi ?

Lorsqu’un projet se passe mal, il convient d’être pragmatique : ce n’est pas le moment de chercher les causes de l’incendie, c’est d’abord le moment de l’éteindre.

Nous dénommons cette recette "pompier" pour ce motif.

L’objectif n’est plus de faire une recette technique ou fonctionnelle : il est de compenser une lacune en tests unitaires en dégageant un maximum d’observations afin de quantifier l’écart entre ce qui a été fait et l’objectif à atteindre.

La détermination du volume des observations permet alors d’estimer la charge de travail à fournir pour rectifier le tir au plus vite.

Une recette "pompier" est donc une opération "coup de poing" pour laquelle une seule ressource est nécessaire le plus souvent, éventuellement une petite équipe : il faut être efficace, rapide et peu coûteux.

a. ORGANISER - Définir un périmètre de manière pragmatique

Le contexte d’une recette d’urgence ne permet pas de formaliser un périmètre de test de manière rigoureuse. Bien sûr, vous aurez probablement des cahiers de recette, des plans de test et tout votre arsenal de recette prêts… sauf que l’application ne permet pas réellement...

a. Quand ?

Le patch est le correctif d’urgence demandé à une MOE suite à un incident détecté en production par le métier (reportez-vous au chapitre suivant : nous y décrivons le processus de collecte des incidents de production).

Il ne s’agit donc pas d’une recette pompier mais d’une réponse très réactive à fournir rapidement nécessairement dans un chantier de maintenance puisque l’application est déjà en production.

b. Quelles contraintes ?

La principale contrainte à gérer est la synchronisation du patch correctif avec les versions de l’application situées dans d’autres environnements, notamment ceux des recettes métier et technique.

Pour peu qu’il y ait une recette en cours, vous ne pourrez d’ailleurs pas fournir le patch immédiatement et la correction sera faite en développement puis livrée dans un autre environnement de test, disponible dans l’instant :

Le caractère urgent du patch fait qu’il n’est pas possible d’attendre qu’un autre processus soit terminé, quel que soit celui-ci, sauf s’il s’agit d’un autre patch avec lequel une synchronisation est nécessaire en raison d’une dépendance.

Par ailleurs, dès lors qu’un patch n’est pas déployé sur les applications situées en recette, cela signifie que ces versions en cours de test ne seront de toute façon, jamais déployées en production telles quelles : il y aura dans la plupart des cas une régression (à de rares exceptions près).

Ceci signifie qu’un patch a une répercussion organisationnelle systématique ou presque : il faut le répercuter sur tous les environnements.

Et les outils conventionnels de gestion de projet ? A-t-on besoin de diagramme de Gantt ou de PERT pour la gestion d’un patch ?

Soyons réalistes : la théorie voudrait que tout...

a. Quand ?

Toujours. Que le chantier soit de release ou de maintenance.

Théoriquement, une recette technique devrait être systématiquement faite avant qu’une équipe métier ne procède à une recette fonctionnelle.

La pratique est toute autre et il est fréquent que la recette fonctionnelle soit cumulée à la recette technique, tout simplement parce que la MOA décide d’externaliser ses recettes auprès d’un prestataire externe expert en tests logiciels.

Ainsi, l’équipe de recette technique prend en charge les deux aspects, situation à limiter toutefois, car il est impératif que la MOA effectue des tests de validation fonctionnelle elle-même.

En revanche, lorsqu’il n’y a pas de structure organisationnelle experte dans les tests technico-fonctionnels, la MOA sera contrainte à gérer cette phase alors qu’elle devrait se limiter à une recette purement fonctionnelle.

L’effort de test peut donc s’avérer insuffisant selon le contexte du projet, plaçant ainsi ses acteurs au pied du mur : la recette "pompier" que nous évoquions au début du chapitre s’imposera alors d’elle-même… malheureusement.

b. Pourquoi ?

Assimiler recette technique et recette fonctionnelle serait une grave erreur.

Car autant une recette fonctionnelle ne revêt pas d’aspects techniques (il s’agit de vérifier que les règles métier sont correctement implémentées et rien d’autre) autant une recette technique devra prendre en compte les technologies et l’architecture employées dans la solution :

a. Quand ?

Une recette fonctionnelle est dite "pure" en langage courant lorsqu’elle n’implique pas une recette technique simultanée, c’est-à-dire que celle-ci a été réalisée au préalable.

La MOA se limite ici à faire des tests de validation fonctionnelle préparés par elle et exécutés sous sa gouverne. Les testeurs pourront être membres de la MOA - voire des décideurs du projet qui souhaitent se faire leur propre opinion - ou bien des utilisateurs finaux spécifiquement désignés pour cette action. 

Bien évidemment, une telle recette ne peut s’effectuer qu’avec une application qui a déjà une relative qualité : pas d’anomalie bloquante, une présentation déjà propre dans sa perception, normalement compatible avec plusieurs configurations matérielles.

b. Pourquoi ?

Le but d’une telle recette est la plupart du temps l’homologation, c’est-à-dire une VABF (vérification d’aptitude au bon fonctionnement).

Son objectif revêt donc un aspect officiel de validation pour signifier qu’un jalon du projet a été franchi avec succès ou pas. Si la MOE est externe, cette VABF aura même des impacts contractuels et des incidences sur la facturation qui est normalement déclenchée pour partie à ce stade du projet.

Le lecteur comprend ici pourquoi il est délicat de cumuler la recette technique et la recette fonctionnelle, et pourquoi un désengagement trop fort de la MOA en matière de test doit être évité. Le principe de partager les tests entre la recette technique et la recette fonctionnelle se trouve ici pleinement justifié : la première structure ne saurait se substituer à la seconde.

Dans les sections qui suivront, nous partirons donc du principe qu’une recette technique aura eu lieu au préalable.

Nous sommes conscients que notre positionnement est ici très théorique… mais la théorie a parfois du bon !