Ne négligeons pas les tests

validation

Nous, informaticiens, avons pour missions d’aider et d’accompagner nos clients dans la réalisation quotidienne de leur tâches en leur mettant à disposition des outils conformes à leurs attentes et en parfaite adéquation avec leurs besoins.
La mise en production d’un programme ou d’une application représente souvent une période de stress, pour les équipes techniques (L’architecture choisie va-t-elle convenir ? Tous les paramètres ont-ils bien été valorisés?...) comme pour les équipes fonctionnelles (Ce qui a été développé va-t-il répondre aux besoins des utilisateurs ? A-t-on bien testé tous les cas de ‘la vraie vie’ ?).

Je vous présenterai dans cet article, l'importance des tests lors d'un projet et de la manière dont la collaboration entre AMOA et MOE devient indispensable pour détecter les anomalies avec succès.

La détection des anomalies lors des phases de tests

Nous savons que le zéro défaut n’existe pas et qu’on a jamais l’assurance d’avoir livré un logiciel sans bug. Néanmoins si les tests ont été menés avec complétude et rigueur, l’incertitude sera gérée avec plus de sérénité.

Si les définitions de besoin et la rédaction/validation des spécifications avec le client, c’est-à-dire le métier, sont souvent passionnantes, si la conception laisse place à notre créativité pour proposer les meilleures solutions techniques, si les développements sont des défis récurrents et constructifs avec un langage et un environnement, les tests représentent la partie fastidieuse qui risque de provoquer des tensions entre les différents intervenants et parfois remettre en cause les choix et orientations pris en amont dans le projet.

Il est important de noter que plus une anomalie est détectée tôt dans le circuit de validation d’un produit, moins elle est coûteuse dans sa résolution, en termes de temps, de délai et d'argent.
Si elle est détectée lors du développement, la correction et les nouveaux tests unitaires s’enchainent immédiatement.
Détectée en phase d’intégration, par la MOE, sa correction oblige un développeur à se plonger dans du code qu’il ne connait pas ou plus.
Relevée en phase de recette, c’est tout un processus de déclaration (suivi, résolution et livraison de correction d’anomalie) qui est mis en œuvre et le délai de livraison de la correction augmente.
Signalée en production, elle entre alors dans un autre circuit d’anomalies encore plus lourd et plus coûteux, avec une nouvelle livraison de version ou de patch correctif….
Plus elle est détectée tardivement, plus elle mobilise des équipes : production, intégration, AMOA, MOE …

Les types de tests selon les instances

Les tests sont réalisés par différentes « instances » de l’équipe projet. Par exemple, si on considère une organisation projet comme suit :
• Maîtrise d’OuvrAge (Client)
• Assistance Maîtrise d’OuvrAge (lien MOA / MOE)
• Maîtrise d’Œuvre (MOE)

Plusieurs niveaux de tests sont réalisés par la MOE :
• Des tests unitaires : on s’assure que le composant développé correspond à ce qui a été demandé dans les dossiers de spécifications,
• Des tests d’intégration :  on s’assure que les différents composants s’assemblent correctement ;
• Des tests techniques : de performance, de montée en charge, de mise en place de flux
• Des tests de non régression : pour s’assurer de ne rien avoir dégradé dans le fonctionnement de la version précédente du composant.

Les équipes de MOE utilisent des données de tests qu’elles adaptent « manuellement » pour tester leurs développements.
En revanche, les recettes AMOA sont effectuées sur de vraies données, afin de disposer des cas nominaux comme des cas extrêmes ou des cas particuliers.
Il s’agit de tests fonctionnels, tests de chaines de bout en bout, tests de non régression.
IL est parfois délicat de tester l’émission/réception de flux avec d’autres applications car elles ne disposent pas forcément d’environnement dédié.

Déclarer l'anomalie en fonction du cadre dans lequel on se trouve

Dans le cas d’évolution de logiciel, les cas de tests et scénarios de tests sont identifiés et élaborés à partir des spécifications fonctionnelles et lors de la rédaction des spécifications détaillées.
Il est très difficile d’accepter, en phase de recette, de signaler des anomalies qui relèvent du test unitaire.
Le travail de recette demande la définition de plan de tests riches et complets. Etre arrêté dans sa campagne de tests par des anomalies de 1er niveau est frustrant et pénalisant.
D’autant que cela atteint la confiance de l’AMOA envers la MOE, remettant en cause la fiabilité et la qualité des produits livrés en recette.
Les anomalies sont en général classées par niveau de gravité croissant, de « mineur » à « bloquante » par exemple, et une anomalie de niveau le plus élevé, bloque dans tous les cas la mise en production, mais peut aussi carrément mettre fin à une campagne de recettes, avec tous les décalages que cela entraîne.

Dans le cadre de la maintenance corrective, les anomalies sont déclarées en environnement de production, pas en phase de recette.
Dans un premier temps, il faut identifier l’origine du dysfonctionnement : bug logiciel ou incohérence dans les données par exemple ?
Cette analyse est souvent menée conjointement avec l’AMOA et la MOE : l’AMOA s’efforcera de reproduire l’anomalie par l’application, et la MOE pourra trouver l’origine de l’anomalie en regardant les données et/ou le code.
En environnement de recette, l’AMOA teste la correction mais s’assure aussi qu’elle ne génère pas des effets de bord.

Une collaboration essentielle entre l'AMOA et la MOE

Dans tous les cas d’anomalies, il est essentiel que l’AMOA décrive précisément les enchaînements fonctionnels qui ont conduit à une anomalie, afin que la MOE puisse, elle aussi, la reproduire.
En retour, il est essentiel que la MOE fournisse à l’AMOA, pour ses tests fonctionnels, les causes de l’anomalie et la solution mise en œuvre.
Si l’AMOA n’a aucune information sur l’origine du dysfonctionnement et la correction qui a été apportée, elle pourra constater que le problème déclaré est résolu, mais ne sera pas en mesure de s’assurer que cette anomalie ne pourra pas se reproduire.
Dans tous les cas, les tests de non régression sont indispensables pour détecter éventuellement les effets de bord du correctif.

Une bonne connaissance fonctionnelle de l’applicatif, en général du domaine de l’AMOA, aide incontestablement à anticiper ces effets de bord. L’idéal est bien sûr d’en alerter en amont la MOE qui y sera sensibilisée et en mesure de les limiter au cours des développements, mais ceux-ci surgissent souvent en cas de recette fonctionnelle plus globale.
Il existe par ailleurs des outils automatiques de test (Sélénium par exemple pour la navigation Web) qui permettent d’enregistrer (comme une macro) ou d’écrire des séquences de tests dont l’exécution sera automatisée dans le navigateur. Ces séquences enregistrées gèrent en partie la non régression d‘une application.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.