Tests logiciels : comment réconcilier qualité et agilité ?

Le test applicatif reste assimilé à une contrainte. Pourtant, la qualité des systèmes n’est pas incompatible avec leur agilité. Encore faut-il passer d'une logique de coût à une logique d'investissement.

C'est l'une des activités les plus dynamiques du secteur de l'informatique : selon une étude du cabinet Pierre Audoin Consultants d'octobre 2010, le marché du test logiciel (ou de la qualification du système d'information) devrait connaître une croissance de 10% par an en moyenne dans les prochaines années. Une accélération qui fait écho à la prise de conscience générale du besoin de qualité des actifs informatiques, tant en termes de services rendus aux métiers que d'image de marque, et de coûts.

Véritable assurance contre les risques (bugs, pannes, etc.) et les coûts cachés (perte d'exploitation, inactivité des équipes, pénalités de retard de livraison, etc.) résultant de la non-qualité, le testing est un investissement qui ne peut plus être négligé. En moyenne, on constate en effet un rapport de 1 à 100 entre le coût de correction d'une erreur en phase de conception et le coût de la même correction en production. Ainsi, plus les tests interviennent tôt dans le cycle de développement des logiciels, moins les coûts de correction sont élevés.

En parallèle, les tests doivent accompagner les enjeux des DSI, à savoir adapter les outils informatiques aux besoins en constant changement des métiers. C'est la raison pour laquelle, les tests ne doivent pas rimer avec sur-qualité, coûteuse et inutile, ni provoquer une certaine inertie du système d'information, néfaste au time to market. La principale difficulté consiste ainsi à trouver le bon équilibre entre des budgets informatiques qui ne sont pas extensibles et le retour sur investissement, que peuvent attendre les métiers d'un système d'information de qualité et agile au changement.

Inscrire les tests logiciels dans une logique métier
Longtemps considérée comme une fin en soi, l'informatique retrouve peu à peu la place qui doit être la sienne dans les organisations : un support aux métiers. Sa qualification doit donc, au-delà des aspects techniques, être fonctionnelle. C'est-à-dire déterminer si l'outil répond, oui ou non, aux besoins définis par les métiers. Des besoins qui peuvent être plus ou moins critiques pour l'activité de l'entreprise. Pourquoi dans ce cas, s'évertuer à tout tester ?

Il faut aujourd'hui faire preuve de pragmatisme, en concevant des jeux de tests et en définissant des taux de défaut toléré en fonction de la criticité des processus métiers, à l'instar de ce qui se pratique dans l'industrie. Par exemple, des processus comme la passation de commandes, la gestion de la livraison font partie, dans la plupart des entreprises, des processus les plus critiques et pour lesquels une erreur en production peut coûter très cher. C'est donc sur ces processus que les tests devront se concentrer.

Parallèlement, et dans le cadre d'une véritable professionnalisation du secteur des tests logiciels, il convient de penser "amélioration en continu". Notamment en organisant des revues qualité, qui permettent d'optimiser les processus de tests eux-mêmes. Pour qu'elles soient efficaces, ces réunions doivent impliquer des équipes mixtes, et donc réunir impérativement du personnel technique et fonctionnel, améliorant ainsi la communication entre les différents intervenants du projet.

Intégrer les tests dès la conception du logiciel
Malgré le développement des méthodes dites "agiles", la méthodologie de conception d'une solution applicative n'a majoritairement pas évolué : spécifications, développement, recettes, mise en production. Et lorsque budgets et/ou délais sont dépassés, c'est bien souvent la phase de recette qui permet l'ajustement, au détriment de la qualité.

Afin d'éviter cet écueil, c'est tout le cycle projet qui doit être repensé. Et notamment par l'implication permanente des intervenants métier, tout au long du cycle projet. Mais aussi, par l'intégration des testeurs dans le projet, dès la phase de conception du logiciel. Afin qu'ils puissent appréhender quels processus critiques, et donc quel périmètre, seront à tester. Objectif : leur permettre de concevoir des scénarios de tests qui serviront ensuite de revue de conception, exécutés sur les prototypes successifs.

Dans cette conception, le rôle des tests devient central, continu et surtout intégré à l'ensemble du cycle projet. De véritables équipes pluridisciplinaires doivent ainsi voir le jour, composées d'un utilisateur, d'un analyste et d'un testeur, permettant aux projets de gagner en performances et en agilité. Des équipes qui partagent une vision commune du périmètre et des objectifs des tests, grâce à un outil commun : le référentiel de tests. Sur lequel, il est alors possible de s'appuyer pour industrialiser les processus de tests et les améliorer en continu, en les outillant et/ou les externalisant.

En intégrant ainsi les tests tout au long du cycle de vie du projet, la qualité ne devient plus un frein à l'agilité du système d'information face à l'évolutivité du métier.

Tests logiciels : se poser les bonnes questions
On le voit, pour concilier qualité et agilité, il convient de rester pragmatique. Et de suivre quelques bonnes pratiques, en se posant les bonnes questions au bon moment. Jusqu'où investir dans les tests et recettes ? Quel périmètre et quel niveau de risque accepter ? Qui intégrer dans les équipes ? Enfin, il s'agit aussi de mettre en place une démarche d'amélioration continue et d'utiliser le cycle projet-maintenance-projet... pour industrialiser et améliorer le processus de test.

Autour du même sujet