La « recette », c’est l’opération par laquelle le client reconnaît que le produit livré par le fournisseur est conforme à la commande passée, qu’il est exploitable dans le système d’informations de l’entreprise, et enfin qu’il est opportun de le mettre à la disposition des utilisateurs.
Pourquoi doit-on tester une application ?
- Pour obtenir, tout d’abord, la satisfaction du client. Mais cette dernière s’obtient progressivement et non pas le jour de la réception
- Parce que le bon fonctionnement de l’application doit être garanti.
Les risques liés aux défaillances doivent être maîtrisés. La réception d’un logiciel n’est pas un exercice de corde raide mais est l’aboutissement d’une démarche maîtrisée.
- Parce que le désordre coûte.
Les modèles itératifs, tel le Unified Process, permettent de démarrer les tests fonctionnels participant à la vérification, beaucoup plus tôt dans le déroulement du projet. La conception des tests peut ainsi démarrer dès que les exigences fonctionnelles d’une itération sont disponibles, et leur exécution dès qu’une version exécutable de l’application est disponible. La validation demeure à la fin du cycle, en raison de son caractère « contractuel ». On observe une croissance exponentielle des coûts d’une anomalie en fonction du moment où elle est découverte (plus on la découvre tard dans le projet, plus elle coûte cher).
Fig. 1 : Charge pour traiter une anomalie
- Pour éliminer le stress lié à l’incertitude
- Parce que l’on a tout à y gagner
ü Diminution des coûts de maintenance,
ü Optimisation de la réception
ü Amélioration de la fiabilisation
ü Satisfaction du travail bien fait
ü Remotivation des équipes
La recette est réalisée selon des procédures qui ne s’improvisent pas. L’anticipation de cette activité permet d’améliorer l’efficacité des tests (simplification et optimisation des tests).
La recette se décompose alors en deux grandes phases :
Phase 1 : La préparation
Cette phase consiste à bâtir la stratégie de test. Il s’agit de planifier les différentes activités sans négliger la préparation logistique nécessaire à une réalisation dans de bonnes conditions.
Phase 2 : La réalisation
Les tests sont réalisés, les bogues sont remontés, le reporting informe le management et un bilan permet d’améliorer la prochaine série de tests.
Fig. 2 : Démarche de planification et réalisation de tests itératifs
La stratégie de tests consiste à déterminer précisément les vérifications qu’il est indispensable de conduire. Elle permettra de définir la méthode à utiliser et les preuves à apporter. Le cahier de recette doit permettre de répondre à quelques questions :
- Qu’est-ce qui sera testé ?
- A partir de quand les tests débuteront ?
- Jusqu’à quelle profondeur les tests seront effectués ?
- Quel planning de tests est envisagé?
- Quelle organisation sera mise en œuvre ?
- Est-ce que l’ensemble de l’application sera concernée par les tests ?
- Quelles preuves tangibles seront fournies pour justifier de la bonne réalisation des tests ?
- …
La stratégie de test doit répondre à plusieurs exigences :
- Elle doit rester souple pour éviter les blocages
- Elle doit intégrer les risques techniques et prévoir des alternatives
- Elle doit rester centrée sur son but: atteindre ses objectifs et identifier les chemins pour les atteindre
- Elle doit être « collaborative » avec les parties prenantes – cela est encore plus vrai en approche itérative: les points de contacts entres équipes doivent être bien identifiés, les « règles de priorité » doivent être claires pour tous.
La gestion d’une campagne de tests doit donc répondre à deux intérêts qui peuvent paraître antinomiques: souplesse et rigueur.¿ |
Ainsi, on s’attachera à garder ces valeurs à l’esprit lors du déroulement d’une campagne de tests afin de trouver le bon équilibre entre la rigueur nécessaire au suivi et à l’évaluation de l’exécution, et la souplesse nécessaire pour s’adapter aux perturbations inévitables.
La démarche globale des tests doit suivre les étapes clé suivantes :
- Définition des objectifs :
Prendre en compte l’ensemble des spécificités du projet : exigences clients, criticité, caractéristiques produit, …
- Estimation et identification des moyens disponibles :
Humains, matériels, logiciel, …
- Planning de mise en œuvre :
Ordonnancement, composants unitaires, responsabilités, environnements informatiques, jeux d’essais, …
- Organisation du processus de réalisation des tests :
Traçabilité, …
- Suivi de l’avancement des tests :
Tableaux de bord de suivi, % avancement, …
- Gestion des écarts :
Résultats obtenus/résultats attendus
- Reporting :
Remontée des points bloquants, …
- Réalisation d’un bilan :
Évaluation des tests
Fig. 3 : Les tests et le cycle de développement
On distingue ainsi sous le nom de vérification les activités de tests visant à s’assurer que le produit développé correspond en tout point à la solution décrite dans le dossier de spécifications ; et sous le nom de validation les tests visant à s’assurer que le produit correspond bien au besoin du donneur d’ordre (La MOA, Maîtrise d’Ouvrage).
La vérification relève donc généralement de la maîtrise d’œuvre et la validation de la maîtrise d’ouvrage. La vérification fait généralement apparaître des défauts de conception et des non conformités fonctionnelles, alors que la validation remonte le plus souvent des défauts dans le recueil des besoins ou des ambiguïtés dans la compréhension et la formalisation des exigences.
La théorie de l’informatique, confirmée d’ailleurs par la pratique, enseigne qu’il est impossible de prouver qu’un logiciel ne comporte aucune erreur. L’application du théorème de Gödel nous permet d’affirmer qu'il est impossible de concevoir un programme capable de vérifier tous les programmes. Certes on peut définir des méthodes de vérification efficaces et les outiller de sorte qu'elles soient faciles à utiliser. Mais ces méthodes, aussi efficaces soient-elles, ne garantissent pas que tous les programmes qu'elles valident soient corrects.
[…] quel que soit le soin que l’on apporte à la définition des tests qu’elle comporte, on n’aura jamais la certitude que le logiciel ne comporte aucun bogue. |
La procédure de recette ne peut donc pas être exhaustive : quel que soit le soin que l’on apporte à la définition des tests qu’elle comporte, on n’aura jamais la certitude que le logiciel ne comporte aucun bogue.
On peut toutefois, et cela relève du bon sens, vérifier qu’il remplit correctement les fonctions essentielles que l’on attend de lui que ce soit en termes de performances, de qualité des données ou d’interface homme-machine. La liste des tests à réaliser doit être établie à froid, avant la livraison du produit ; elle porte le nom de « cahier de recette ».
La combinatoire des tests possibles étant infinie, le cahier de recette constitue une sélection au sein de cette combinatoire. Certains tests sont coûteux en raison de la volumétrie ou des difficultés techniques qu’ils impliquent. Comme le budget accordé à la recette est limité, le cahier de recette doit idéalement comporter la liste de tests la plus efficace pour un coût donné. Il est nécessaire d’adapter la démarche de tests au cycle de vie et à la criticité du projet.
Fig. 4 : Positionnement des tests dans le déroulement d’un projet
Il faut que la recette soit effectuée en partant de « vraies données » et non de données de qualité parfaite. On sait en effet qu’en informatique de gestion, les données sont souvent, pour des raisons parfaitement compréhensibles, de qualité variable (codages imparfaits, données manquantes, vérifications insuffisantes). C’est par rapport à cet état de fait qu’il faut évaluer la qualité de l’opération, et non par rapport au monde idéal où les données seraient sans défaut.
Il faut préciser le protocole selon lequel la recette sera organisée : quelles seront les tâches qui incomberont au client, celles qui incomberont au fournisseur ; quels seront les documents qu’ils devront se communiquer; dans quel ordre les tests seront réalisés ; quels seront les seuils d’acceptation du produit. Si le protocole n’est pas défini à l’avance, le risque de conflits entre client et fournisseur sera élevé.
Recette « usine » et recette « utilisateur » :
On distingue deux étapes dans la recette : la « recette usine », faite avant la livraison du produit par le fournisseur, permet à celui-ci de vérifier que le produit est conforme à la commande reçue ; la « recette utilisateur » est faite par le client après livraison.
La recette usine
Il faut que le compte rendu de la recette usine soit livré par le fournisseur en même temps que le produit : ce compte rendu apportera au client la preuve que le produit a été sérieusement testé avant sa livraison, et permettra de gagner du temps en ne refaisant pas les tests déjà réalisés par le fournisseur. Il faut prévoir la livraison du compte rendu de la recette usine dans le protocole de recette, sinon le client aura du mal à l’obtenir.
Lors de cette phase, on réalise des tests unitaires et des tests d’intégration. Les tests unitaires permettent d’assurer les fondations de la construction logicielle. Ces tests permettent de limiter les écarts par rapport à toutes les spécifications du composant à tester et d’assurer la fiabilité de la phase de codage/paramétrage.
Quant aux tests d’intégration, ils permettent d’assurer un bon fonctionnement de l’assemblage logiciel/logiciel et logiciel/matériel.
La recette utilisateur comporte deux étapes :
ü une recette technique, réalisée par la direction informatique du client, vérifie que le produit est exploitable sur la plate-forme informatique de l’entreprise (compatibilité avec ses matériels, systèmes d’exploitation et logiciels) et que la performance physique est acceptable (volumétrie des bases de donnée et des flux de messages, délais d’affichage sur les écrans des utilisateurs, robustesse en exploitation [évaluation du système aux cas limites]). Des tests de respect de l’ordonnancement sont également réalisés. L’objectif étant de vérifier la dynamique des tâches temps réel (synchronisation, priorités, parallélisme, précédence,…);
ü une recette fonctionnelle, réalisée par la maîtrise d’ouvrage, vérifie que le produit fournit les fonctionnalités demandées par le cahier des charges et qu’il est acceptable par les utilisateurs.
La stratégie de tests doit également comporter une stratégie de tests de non régression.¿ |
Les anomalies détectées :
Les tests détectent des anomalies ; chacune d’elles fait l’objet d’une «fiche d’anomalie» envoyée au fournisseur. Celui-ci corrige les anomalies jusqu’à convergence des tests. Il arrive parfois que la correction d’une anomalie provoque d’autres anomalies, ce qui peut obliger à refaire des tests qui avaient auparavant donné un résultat acceptable. On parle alors de tests de non régression permettant de s’assurer que les modifications effectuées dans le logiciel ne dégradent pas son comportement validé antérieurement. Ces tests sont à demander au fournisseur mais le client se doit de vérifier la non régression. Cela suppose alors de pouvoir comparer avec des résultats passés :
- Scénarios de tests
- Base de données d’essais
- Environnements identiques
La stratégie de test doit également définir une stratégie de non régression.
Il est normal, inévitable même, qu’un logiciel d’une certaine importance contienne des erreurs : la détection d’anomalies au début de la recette n’a donc rien de scandaleux, même si elle suscite toujours une tension entre client et fournisseur. Le véritable critère de qualité réside dans le délai de correction des anomalies : si ce délai est long, si les corrections suscitent d’autres anomalies de telle sorte que le volume d’anomalies à traiter ne diminue pas, le client doit s’interroger sur la qualité du logiciel et sur son évolutivité.