Le Coût des Tests

Longtemps la qualité logicielle a été absente des budgets

Jusque vers le début des années 1990, la qualité des applications informatiques n’est pas une priorité pour les directions informatiques. Les défaillances applicatives sont certes gênantes, entraînant des ruptures dans la continuité du service et des charges de correction qui peuvent parfois désorganiser les équipes techniques. Mais cela ne conduit pas pour autant à se poser la question du coût de la non-qualité.

Les principales raisons de cette situation tiennent d’une part au degré relativement faible d’interconnexion des applications et d’autre part à la place assignée à l’informatique d’entreprise.

Dans cette période, les applications informatiques sont relativement indépendantes les unes des autres. La défaillance d’une application, pour handicapante qu’elle puisse être localement, a un impact limité sur l’ensemble de la vie de l’entreprise. De même, le faible taux d’échanges automatisés avec l’extérieur limite d’autant la propagation de l’impact de ces défaillances. « Ça ne sort pas de la famille »…

Parallèlement, les directions informatiques ont un poids très important dans l’entreprise. Chargées d’assurer une transformation radicale de son fonctionnement, par l’automatisation des processus, avec comme visée première la réduction du nombre de postes de travail, leurs budgets sont à la mesure des gains escomptés et la rationalisation budgétaire n’est pas nécessairement à l’ordre du jour.

Enfin, la faible maîtrise des utilisateurs en matière de manipulation de l’outil informatique autorise à interpréter les défaillances techniques comme pouvant résulter de la maladresse humaine et il n’est pas rare de constater que les solutions de contournement remplacent de véritables corrections.

À cette époque, la mise en place des cadres normatifs liés à la qualité (ISO 9000) est plus perçue comme une contrainte formelle destinée à promouvoir un avantage concurrentiel, que comme une incitation à approfondir le questionnement et les pratiques pour faire mieux.

Dans ce contexte, le test informatique, souvent confié aux informaticiens eux-mêmes, se voit au mieux attribuer un inconfortable strapontin dans les projets (budget, ressources, plannings) et sa méthodologie est inexistante. Souvent considéré comme la variable d’ajustement des projets, sa mise en œuvre peut produire des résultats très formels mais sans réelle garantie pour la qualité de l’application testée.

mais les conséquences de la « révolution informatique » ont changé la donne.

A la fin des années 1990, l’anticipation du « bug de l’an 2000 » a forcé la prise de conscience du risque logiciel : impossible de se soustraire à l’effort d’analyse et de correction des applications, sous peine de conséquences lourdes voire incalculables, non seulement pour l’entreprise, mais pour l’ensemble du tissu socio-économique concerné, partout sur la planète.

Le souvenir alors récent du crash d’Ariane 5, dont la cause était identique, dans son principe, au problème soulevé par le bug de l’an 2000, rappelait l’importance vitale non seulement de corriger, partout, mais surtout de vérifier la conformité de la correction afin de garantir l’absence de toute défaillance.

Cette prise de conscience du poids de l’interdépendance applicative et des impacts potentiels de la non-qualité a été renforcée par l’accroissement progressif de l’inter-opérabilité des applications, non seulement dans ce que l’on appelle désormais le système d’information de l’entreprise, mais aussi entre les entreprises et, depuis quelques années, entre les entreprises et les particuliers.

Favorisé par les constantes évolutions technologiques, ce phénomène a transformé l’informatique en « fluide informationnel » irriguant la vie des entreprises et des particuliers, à l’image de ce fluide énergétique qu’est l’électricité. Pour certains secteurs d’activité, tels la banque ou l’assurance, elle est même devenue le noyau autour duquel gravite une part significative de l’activité humaine.

Au vu des enjeux et des contraintes impliqués par ce changement de paradigme, le risque logiciel ne peut plus être ignoré ou même sous-estimé, car ses impacts peuvent engager la survie de l’entreprise voire de ses partenaires. L’évolution du corpus normatif (ISO, ITIL, CMMI, etc…) depuis 25 ans est à cet égard significatif.

Parallèlement, la « révolution informatique » étant accomplie, l’importance des directions informatiques a décru, et les budgets sont désormais plus surveillés.

Dès lors, comment justifier, dans des budgets plus contraints, le poids significativement croissant du test informatique, activité jusqu’alors sans réel impact budgétaire, mais désormais inéluctable ?

Un coût lisible pour des décisions appropriées

Le coût de la non-qualité logicielle, s’il n’est pas toujours lisible, n’en est pas moins réel.

Il n’est pas fréquent de trouver des structures informatiques en mesure d’extérioriser précisément le coût de correction des incidents imputables à une application donnée. Bien souvent, les suivis budgétaires n’atteignent pas ce degré de précision. Et quand bien même ce serait le cas, il manquera encore les coûts induits par les dysfonctionnements, supportés par les services utilisateurs, les partenaires extérieurs ou les clients : rupture de service, mise en place de solutions de contournement, reprises de données après correction, dédommagement de tiers lésés, etc.

De tels coûts, objectifs et objectivement liés au degré de qualité des applications, devraient en toute logique être supportés par les projets afférents (MOA et MOE), ce qui n’est pas souvent le cas.

Or, la connaissance du métier, alliée à une définition précise des fonctionnalités attendues de l’application, permet d’identifier a priori les risques portés par la défaillance de ces fonctionnalités et d’en évaluer le coût. Il devient alors possible d’estimer un ordre de grandeur du coût potentiel de la non-qualité de l’application.

Face à ce type d’estimation, le retour d’expérience et le recours à une méthodologie de test permettent désormais de construire avec précision des projets de test et d’en estimer un coût détaillé (charges de conception et d’exécution des tests, compétences, outils, environnements, etc.), qui peut être opposé à celui de la non-qualité potentielle ainsi qu’au budget du projet de développement.

Ce coût estimé et lisible de la qualité peut à tout le moins être débattu et argumenté sur des bases concrètes.

Là où des coûts insuffisamment extériorisés peuvent soulever de fortes réserves, afficher des coûts structurés, lisibles et opposables permet d’abaisser significativement le degré de réticence et d’engager la négociation.

Retour sur Investissement pour un centre de coût ?

« Quel retour sur investissement puis-je espérer du coût engagé pour garantir la qualité de mon application ? »

Cette question fréquemment entendue révèle un contresens sur la nature du coût de la qualité, signe le plus souvent d’une réticence à accepter de payer pour contrôler la qualité d’une application.

Nous voyons deux raisons à cette réticence, l’une liée à l’histoire de la place du test dans les projets et dans les budgets, l’autre à la nature de l’activité de contrôle de la qualité.

Historiquement, on l’a vu, le test était une activité annexe des métiers de l’informatique, peu considérée et peu développée et il a pu être tentant de voir dans son amplification un pur effet de mode, voire une revanche des « qualiticiens ».

Quant à sa nature, contrairement au développement, qui produit des composants bien réels, palpables, et dotés d’une valeur ajoutée « monnayable » en termes de gains de productivité internes ou revendus, le test ne produit rien d’autre que la trace de ses propres actions. Au terme de cette activité, l’application n’aura rien gagné en valeur ajoutée. Pourquoi dès lors payer, et parfois cher, pour une activité qui ne produit rien ?

Le crash d’Ariane 5 aurait coûté 3000 fois plus cher que l’économie réalisée par l’abandon des tests de régression qui est cause de ce crash. Le coût de prévention du bug de l’an 2000 a été estimé entre 100 et 200 milliards de $ en Europe, mais quel aurait été le coût entraîné par les défaillances si rien n’avait été fait ? Ces exemples montrent que seul le coût de la non-qualité peut être opposé à celui de la qualité.

Dès lors, la question à poser serait plutôt: « quel peut être le coût de la non-qualité et combien suis-je prêt à mettre sur la table pour éviter ce coût ?« .

La qualité d’un produit n’est pas tout le produit, mais seulement un de ses attributs. C’est l’assurance raisonnable de la fiabilité du produit, argumentée par le résultat des tests. Le prix consenti pour la qualité est celui d’une assurance contre les défauts du produit, lesquels pourraient mettre en péril sa valeur ajoutée pour l’entreprise.

En termes comptables, une assurance est une charge et non un investissement.

Il n’y a donc aucun retour sur investissement à attendre du test informatique, mais seulement un niveau de garantie de pouvoir utiliser ou vendre l’application sans surcoût majeur pour cause de défaillance.

Si les services de développement informatique peuvent parfois être considérés comme centres de profit, l’assurance qualité ne peut être considérée que comme un centre de coût.

Le coût réel des tests peut être affecté par le poids des anomalies détectées

L’effort de test estimé dans le budget d’un projet dépend en partie de la part qui sera consacrée aux anomalies, principalement leur détection, leur confirmation et le test des corrections. Dans le budget initial du projet, cette part est estimée sur la base d’une quantité prévue d’anomalies et de l’effort moyen pour les traiter.

Or, le degré réel de non-qualité de l’application peut engendrer, au fil du projet, un coût de traitement des anomalies supérieur aux prévisions. De plus, l’immersion d’une nouvelle application dans le système d’information peut révéler des failles latentes de ce dernier et conduire à des actions correctives non prévues.

Le projet peut alors se retrouver devant le choix d’une dérive non maîtrisée (budget, planning, ressources, etc.) ou de mettre en production une application porteuse de défaillances au conséquences non-évaluées.

Optimiser l’effort de test renforce la maîtrise des coûts et des risques

Toutes les défaillances applicatives n’ont pas le même poids pour l’entreprise : si certaines d’entre elles peuvent entraver localement le fonctionnement d’un service sans présenter de risque majeur, d’autres peuvent compromettre gravement l’ensemble voire engager la survie de l’entreprise.

• l’évaluation initiale portera sur tous les composants à tester, mais l’effort de test consenti pour chacun d’entre eux tiendra compte de sa priorité. On sera donc en mesure de tester potentiellement tous les composants, avec un effort adapté,
• pendant le déroulement du projet, les composants les plus prioritaires étant testés en premier, les dérives éventuelles pour surcroît d’anomalies pourront être, au moins partiellement, absorbées par un allègement de l’effort sur les composants les moins prioritaires.

Cette méthode présente plusieurs avantages :

• le risque de non-qualité de l’application est anticipé et, le cas échéant, pris en connaissance de cause,
• les arbitrages budgétaires en cours de projet sont facilités. Si l’absence de dérive ne saurait être garantie, du moins dispose-t-on d’un moyen d’en maîtriser le poids,
• en aval, la connaissance du périmètre applicatif peu ou pas testé permet une surveillance ciblée de l’application en production et optimise la réaction aux éventuels incidents,
• en amont, la connaissance a priori du niveau de risque porté par les composants à mettre en œuvre, par une attention particulière portée à leur réalisation, pourra avoir une influence positive sur leur qualité, réduisant de facto la quantité et la gravité d’anomalies potentielles.