L’efficacité des tests logiciels dépend de leur place sur le chemin critique
Longtemps, les tests ont été considérés comme un mal nécessaire, sorte d’obligation plus ou moins bien assumée et que l’on plaçait au bout du chemin critique du projet, juste avant la mise en production.
Les principaux inconvénients d’un tel choix sont :
- effort insuffisant consacré à la préparation des tests et à l’identification des tests prioritaires,
- coût important de la correction des anomalies : ce coût augmente de façon exponentielle non seulement avec le délai de détection mais aussi avec la phase de mise en œuvre remise en question par l’anomalie détectée. Le coût de correction peut s’avérer incompatible avec le budget résiduel du projet,
- phase de test souvent considérée comme variable d’ajustement du projet. Placée ainsi, elle est trop souvent l’otage d’une double contrainte : dépassement cumulé des budgets et plannings des phases antérieures, date non déplaçable de mise en production.
Une telle organisation des tests fait courir un risque important à la qualité du logiciel produit, tant par la qualité insuffi- sante des tests effectués que par la faiblesse de la couverture testée (étendue, profondeur et priorités).
A partir de la fin des années 1990, le test logiciel s’est professionnalisé, devenant peu à peu un métier à part entière de l’informatique. Les questions méthodologiques ont été abordées, permettant de définir des modes d’organisation de cette activité en phases parallèles aux phases de réalisation.
Ce parallélisme permet à la fois de consacrer une part plus importante du planning aux tests et de diversifier les compétences selon les types de test effectués. Les principaux avantages induits par cette évolution sont :
- une meilleure maîtrise du risque logiciel, par une couverture des tests plus large et des priorités mieux définies
- une détection plus précoce des anomalies, influençant positivement le coût de leur correction,
- une amélioration dans la maîtrise des budgets et des plannings spécifiques de l’activité de test.
Malgré tout, le risque persiste de détecter tardivement des anomalies dues à des déficiences dans la conception de l’application ou dans l’expression des exigences. L’organisation portant ici sur le test de composants produits par les équipes techniques, il n’a pas d’impact sur la vérification des livrables en amont. A l’extrême, le risque persiste de mettre en production une application totalement conforme à ses spécifications, mais parfaitement inutilisable, du fait d’exigences inappropriées au besoin réel.
La qualité logicielle se prépare en amont…
A problème mal posé, solution inappropriée et tous les efforts pour redresser la situation a posteriori seront vains ou se feront à un coût démesuré en termes d’effort, de temps et de budget.
Ceci est particulièrement vrai dans le cas de l’informatique d’entreprise, principalement du fait d’une collaboration encore trop souvent défaillante entre ceux qui définissent le besoin (les équipes métier), ceux qui sont chargés de traduire ce besoin en applications efficaces et fiables (les équipes informatiques) et ceux qui sont chargés d’en contrôler la qualité (les équipes de test).
Les distorsions de communication entre ces équipes engendrent des failles dans l’appropriation et la compréhension du besoin et de ses impacts sur l’application à mettre en œuvre. Ces failles sont rarement perceptibles en tant que telles, mais leur effet se révèle le plus souvent très tard, au travers des défaillances de l’application, durant les tests, voire après la mise en production.
Une illustration à peine caricaturale de cette situation est le cas où l’équipe informatique prend en charge un besoin sans en vérifier la pertinence et la cohérence et où l’équipe de test procède aux contrôles sans avoir vérifié pertinence et cohérence de la conception.
Remédier à cette situation revient à impliquer ces trois grands acteurs ensemble, sur la totalité du projet et considérer que le contrôle qualité s’applique à tous les livrables et pas seulement à ceux produits par les équipes informatiques. Par ce moyen, on réduit fortement le risque de découverte tardive de défaillances et l’ensemble du projet gagne en cohérence et en efficacité.
… et s’entretient en aval
La nécessité de contrôler la qualité d’une application avant sa mise en production est désormais un acquis et on trouvera peu d’avis contraires argumentés avec pertinence.
Pour autant, un tel contrôle peut-il être considéré comme suffisant ? Rien n’est moins sûr, car rien ne garantit qu’une défaillance ne puisse apparaître pendant la période de production. En revanche, les enseignements tirés des tests peuvent servir à anticiper de possibles défaillances en période de production.
En particulier, il est fréquent de constater que les performances atteintes et contrôlées durant la période de test subissent des dégradations au fur et à mesure de l’utilisation, notamment pour celles qui fonctionnent dans un contexte de forte sollicitation (nombreux utilisateurs ou services techniques à haute fréquence).
Suivre en temps réel l’évolution des performances et comparer ces mesures à celles obtenues durant la période de test permettra d’anticiper la survenue d’interruptions de service, de bénéficier d’un dispositif d’alerte et de mettre en œuvre des correctifs avant que de telles défaillances surviennent. Cette activité de suivi des performances est le rôle d’une activité qui se met en place progressivement depuis quelques années, connue sous le nom d’APM (Automatic Performance Monitoring).
Le processus de contrôle qualité ne s’arrête donc pas avec la mise en production. Il change simplement de nature :
- en amont de la mise en production, on vérifie la conformité de l’application à des exigences posées sur le papier,
- en aval, on fait de la prévention d’éventuelles défaillances, en confrontant les mesures opérées sur le terrain avec le comportement attendu de l’application, matérialisé par les résultats aux tests.