Journal du Net > Solutions > DSI > DSI > Analyses > 4 étapes pour optimiser ses tests logiciels
ANALYSE
 
02/05/2007

4 étapes pour optimiser ses tests logiciels

De la définition des exigences à l'optimisation du processus, le test applicatif prend le chemin de l'industrialisation, poussé en ce sens par des clients exigeants. Le point sur quelques bonnes pratiques.
  Envoyer Imprimer  

 
En savoir plus
 
 
 

Durant une décennie, les tests logiciels sont restés à l'état d'activité assez artisanale. Un cahier des charges de test était élaboré en lien avec la maîtrise d'ouvrage, dans le but de spécifier la phase de recettage. De leur côté, les techniciens réalisaient des tests unitaires et de débogage, éventuellement à l'aide d'automates.

"La qualité des tests dépendait de la qualité du cahier des charges. Il n'y avait aucune mise en commun des cas de test et de la connaissance issue de ce processus", commente Jean-Louis Marty, directeur délégué de Compuware France. Mais ces dernières années, on a assisté à une prise de conscience de l'importance de cette démarche au sein des DSI et des équipes de projets, qui conduit aujourd'hui à la mise en place de politiques d'industrialisation des tests. Ces dernières répondent généralement à quatre étapes bien distinctes.

1) La définition des exigences
En amont de cette démarche, la définition de la phase de test commence par l'analyse des exigences fonctionnelles, en lien avec la maîtrise d'ouvrage. "Au lieu d'exprimer des besoins fonctionnels vagues, l'idée est de définir de manière précise les chemins de l'application à l'écran, en vue de structurer ensuite la phase de test", explique Jean-Louis Marty.

La modélisation de l'application permet de générer l'ensemble des chemins de test possibles. Des solutions telles celles de Compuware permettent de tirer un référentiel de tests d'un modèle UML, Mega ou Rational Rose.

2) La sélection des chemins à tester
Mais une fois l'ensemble des chemins de test possibles inventoriés, il est nécessaire dans beaucoup de cas d'en réaliser une sélection. Vu leur nombre, il est en effet impossible de tous les éprouver.

"Il est recommandé d'appliquer une méthode de Risk-Based Testing, afin de déterminer une stratégie de test en fonction d'une analyse de risque, au regard de la criticité des chemins", poursuit Jean-Louis Marty. Sur cette base, les tests à réaliser sont hiérarchisés et des critères de qualité requis leur sont associés. Le tout est archivé après avoir été validé par la MOA et la MOE.

3) Outiller le processus
L'utilisation d'outils contribue également à structurer et surtout faciliter le travail de test en tant que tel. Des solutions de gestion de référentiels et de gestion de configurations aux outils de test fonctionnel, en passant par les outils de test de performance et de charge, toute une pléiade de produits existent pour supporter les différentes tâches du processus.

"A ces applications s'ajoutent des logiciels de pilotage, combinant workflow et interfaces de reporting, conçus pour gérer et suivre l'état d'avancement des différentes étapes de test", commente François Darphin, directeur technique chez Sogeti Application Services Ile-de-France.

Le référentiel de test : une base de connaissances qui s'enrichira au fil des développements

Aux côtés de Compuware, beaucoup d'autres éditeurs proposent des suites couvrant la plupart de cette palette fonctionnelle. Parmi les plus importants d'entre eux figurent Mercury, IBM (avec la suite Rational), ainsi que Borland. Il ne s'agit que de quelques exemples.

4) L'optimisation du processus
La maintenance d'un référentiel permet de bénéficier d'une base de connaissances qui s'enrichira au fil des nouvelles versions et évolutions des applications. "Elle constituera un socle pour faire des analyses d'impacts lors d'un changement d'exigence", souligne François Darphin. "Les anomalies résiduelles, c'est-à-dire les anomalies qui sont passées sans avoir été repérées à l'origine, pourront y être répertoriées également." Cette traque permanente contribue à enrichir les connaissances sur les niveaux de risque, et la manière d'anticiper les bugs.

 
En savoir plus
 
 
 

Si les anomalies sont nombreuses, il est recommandé de s'interroger sur les causes de ce manque de qualité. L'analyse peut alors remonter bien en amont.

"Les problèmes peuvent être dus à un déficit de qualité du développement, à des contraintes de gestion de projet trop fortes, en termes de timing ou de coût par exemple, ou encore des exigences mal formulées", conclut François Darphin.

 


JDN Solutions Envoyer Imprimer Haut de page

Sondage

Votre entreprise évolue-t-elle vers une informatique bimodale ?

Tous les sondages