Blog ENI : Toute la veille numérique !
Dernière chance (fin le 29/02) : -25€ dès 75€ sur les livres en ligne, vidéos... code FUSEE25. J'en profite !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Gestion des tests logiciels
  3. Organiser une recette
Extrait - Gestion des tests logiciels Bonnes pratiques à mettre en oeuvre pour l'industrialisation des tests (2e édition)
Extraits du livre
Gestion des tests logiciels Bonnes pratiques à mettre en oeuvre pour l'industrialisation des tests (2e édition) Revenir à la page d'achat du livre

Organiser une recette

Concepts généraux dans l’organisation du travail

Si nous partons du principe que la gestion des tests peut s’avérer être "un projet dans le projet", alors la démarche projet pourra s’appliquer à cette seule partie. Nous considèrerons que le lecteur a ici acquis les bases des concepts de la gestion de projets. Ce qui n’empêche en rien une piqûre de rappel.

1. Le diagramme de Crosby Turtle

Comme tout projet, le point de départ de votre analyse pourra être tout simplement un diagramme de type "Crosby Turtle" dont voici le célèbre item de base :

images/05DP01.PNG

Sur ce principe, nous décomposerons la recette en quatre étapes principales que nous nommerons ORGANISER, PRÉPARER, EXÉCUTER et CLÔTURER ce qui donnerait le schéma suivant (volontairement incomplet) :

images/05DP02.PNG

Une cinquième tâche que nous nommerons PILOTER courra tout le long du projet et désignera spécifiquement l’activité du chef de projet de la recette s’il y a lieu.

Nous utiliserons ces mots explicitement pour désigner ces phases tout au long de ce chapitre.

2. Les diagrammes de PERT et de GANTT

Bien évidemment, et comme pour tout projet, les diagrammes de PERT de précédence et de Gantt pour la planification seront des outils très appréciables pour vos recettes.

Le diagramme de PERT...

La recette "pompier"

1. Le contexte

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.

2. Gérer une recette d’urgence

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...

La recette d’un patch

1. Le contexte

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 :

  • Celui de recette technique si celui de recette métier n’est pas exploitable.

  • Réciproquement, celui de recette métier si celui de recette technique ne l’est pas.

  • Et parfois un autre environnement (comme la pré-production) si aucun des environnements de recette ne permet le test du patch.

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...

La recette technique

1. Le contexte

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 :

  • Tests hors domaine ou à des valeurs clés (le dépassement de capacité par exemple, l’usage des caractères spéciaux…). Il s’agit le plus souvent de tests de bas niveau que l’on regroupe dans des fiches de test.

  • Tests de robustesse spécifiquement techniques. Par exemple pour les applications web, des injections SQL pour tenter de forcer une authentification, des injections de HTML aussi, des tentatives frauduleuses d’usage de la barre d’adresse, la désactivation du JavaScript, le test du timeout session, les authentifications multiples…

  • Tests de compatibilité des configurations...

La recette fonctionnelle "pure" ou VABF

1. Le contexte

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 !

2. Gérer la recette fonctionnelle

L’organisation d’une recette fonctionnelle est relativement similaire à celle d’une recette technique. Nous la définirons donc...