Les programmes informatiques sont devenus omniprésents, et le phénomène tend à s’accentuer avec l’ère du « tout connecté ». Tout ce que nous ferons demain sera analysé, comparé et enregistré, et nos décisions seront scientifiquement assistées. Dès maintenant, il est possible d’être présent partout sans y être physiquement, grâce à des logiciels embarqués dans les objets du quotidien. Avec une conséquence de taille : pèse-personne, cafetière, voiture ne sont plus épargnés par des bugs informatiques ! Pour que chacun puisse bénéficier des avantages de ce monde connecté sans ces inconvénients, la qualité des logiciels est donc, plus que jamais, une condition essentielle.
Cette notion de qualité logicielle regroupe plusieurs disciplines traitant des techniques de conduite de projet, de modélisation de processus, de mesure et de contrôle. Toutes sont chargées de s’assurer que le projet sera estampillé « OTOBOS » (On Time, On Budget, On Specs).
Un produit de qualité est un produit fiable
De manière concrète, un produit de qualité est un produit fiable, conforme aux exigences, robuste, dont les fonctions sont sécurisées et prévisibles. Dans les faits, les techniques de vérification et validation utilisées dans des industries avec zéro tolérance de panne (nucléaire, médical, aéronautique, transport, défense…) ne sont pas applicables, faute de ressources financières et de temps, dans la plupart des projets informatiques, où l’impact d’une défaillance reste mesurable et acceptable. Il est même préférable dans certains cas de d’assumer une défaillance que de payer la couverture du risque : mais une telle approche doit être décidée en réelle connaissance de cause et consigné dans l’analyse des risques.
Il reste cependant une technique de vérification et de validation réaliste et adaptée aux projets informatiques : le test et recette. C’est un métier à part entière, très différent du développement logiciel et de l’exploitation informatique.
Chaque acteur a sa méthode et ses outils de test, avec son lot d’arguments pour et contre. Celle présentée ici ne prétend pas être meilleure qu’une autre. Elle est le fruit de passionnés du domaine, qui ont souhaité la partager.
Aujourd’hui les entreprises ont bien compris l’importance de la recette et de la qualité logicielle. Les activités de test sont présentes à chaque étape du cycle, depuis l’expression des besoins jusqu’à la mise en production et c’est ainsi qu’elles contribuent à la qualité logicielle.
Idées reçues, idées fausses…
Malgré cela, le domaine du test a souffert pendant plusieurs années d’un certain nombre d’idées fausses. En 2013, beaucoup d’entre elles sont en voie de disparition, le rôle et l’importance des activités de test étant largement connu et accepté. Il devient ainsi de plus en plus rare d’entendre les assertions suivantes :
- « Le développeur est le plus à même de tester son programme »,
- « Le test et la recette constituent de simples formalités »,
- « Le test est essentiellement l’affaire de la maîtrise d’œuvre (MOE) »,
- « Les outils logiciels règlent tous les problèmes d’homologation applicative »,
- « Le Plan d’Assurance Qualité (PAQ) garantit la qualité d’une application et la dispense de tests approfondis »,
- « Les progiciels de gestion intégrés (ERP) n’ont pas besoin de test »,
- « La garantie d’un projet réussi, c’est la sous-traitance au forfait ».
D’autres se rencontrent encore dans certaines organisations, en fonction de leur degré de maturité et de leur expérience dans le test :
- « Le test coûte cher »,
- « Les tests préparent la recette mais ne mesurent pas la qualité »,
- « La connaissance exclusive de l’environnement technique ou fonctionnel est indispensable à l’activité de test ».
Enfin, quelques idées demeurent bien ancrées, révélant que certains aspects des tests sont encore méconnus ou flous :
- « Réorganiser globalement son activité de test et recette est une décision facile à prendre et très difficile à mettre en œuvre »,
- « Les nouvelles méthodes de développement repensent entièrement les tests »,
- « L’excellence dans le test et la recette, c’est uniquement une équipe spécialisée et des infrastructures techniques dédiées ».
L’objectif de cet article est d’éclaircir ces zones de flou, mais aussi d’entériner les progrès acquis et d’inscrire le test comme un contributeur majeur dans la qualité logicielle. Il souhaite démontrer que le test n’est pas qu’un poste de coût, mais que bien conçu et bien géré, il devient rapidement un facteur de gain facile à mettre en œuvre et à prouver.
Un outil pour partager les expériences et faire connaître les métiers du test
Ce cahier s’appuie sur le travail d’ingénieurs-consultants présents sur le terrain tous les jours, pour certains depuis vingt ans. De ces expériences concrètes, il est possible de tirer des enseignements et des conseils pragmatiques destinés aux professionnels du test, aux personnes à la recherche de solutions pour améliorer la qualité logicielle, mais aussi à tout individu curieux de découvrir ce métier.
Qu’est-ce que la qualité logicielle ?
S’il est possible de trouver des statistiques sur la réussite ou l’échec des projets informatiques, les taux de réussite sont généralement évalués à partir d’un questionnement portant sur le projet et les conditions de son déroulement : le projet a-t-il été terminé ou abandonné et, s’il est terminé, dans quels délais et avec quelle incidence sur le périmètre applicatif initialement projeté ?
La capacité d’alignement sur les objectifs
Or, dans de nombreux cas, dont le plus connu est celui du vol 501 de la fusée Ariane 5, l’échec du projet relève de la seule question de l’aptitude des applications informatiques à remplir les objectifs qui leur sont assignés.
La réussite ou l’échec d’un projet informatique ne se mesurent pas à la seule aune du respect des délais, des charges, du budget et du périmètre applicatif, mais, bien plus fondamentalement, à la capacité de l’application produite par le projet à remplir les objectifs qui lui sont assignés.
Parmi les facteurs de risque observés dans les projets qui échouent figure la primauté donnée au respect des contraintes de budget et de délai, facteur de risque majeur lorsque ces contraintes ne sont pas contrebalancées par une exigence de qualité définie de façon précise et mesurable. L’expérience montre en effet que, bien souvent, les budgets et les délais sont arrêtés en dehors de toute vision précise de ce qui est attendu du projet. Dès lors, un respect aveugle de ces seules contraintes se fait au détriment de la qualité.
Mais qu’est-ce donc que cette « qualité » d’une application informatique et pourquoi ne fait-elle pas partie, au même titre que le budget et les délais, des paramètres structurant la gouvernance de tout projet informatique ?
Selon l’AFNOR, un produit ou service de qualité est un produit « dont les caractéristiques lui permettent de satisfaire les besoins exprimés ou implicites des consommateurs ».
Cette définition convient d’autant mieux aux applications informatiques que dans une majorité de cas, les défaillances des applications sont dues à un défaut de précision et/ou de complétude dans les exigences exprimées par le maître d’ouvrage et prises en compte lors de la mise en œuvre. De ce point de vue, le fait de disposer d’une équipe de maîtrise d’œuvre maîtrisant le domaine fonctionnel concerné peut avoir des impacts opposés : impact positif lorsque la maîtrise d’œuvre complète de façon pertinente les « trous » dans les spécifications et les exigences ; impact négatif quand la maîtrise d’œuvre interprète de façon inappropriée les compléments à apporter à ces manques.
Les trois leviers de la qualité
Cette distorsion entre le besoin réel et l’application produite est un phénomène identifié depuis longtemps.
La qualité résulte de la convergence de trois éléments :
– les besoins,
– les spécifications,
– la réalisation.
A l’évidence, l’objectif ultime est un recouvrement parfait des trois cercles. A l’inverse, tant que cet objectif n’est pas atteint, cela se traduit par des écarts de différentes natures :
- les écarts critiques, dont les conséquences font peser un risque sur la marche de l’entreprise du fait de l’inadéquation de l’application aux besoins. Il s’agit des besoins non satisfaits, des non conformités et des fonctions inutiles. Ces écarts pourront occasionner une rupture dans la continuité du service à des niveaux divers, avec des conséquences non mesurables a priori. Les non conformités induiront des incidents de fonctionnement entraînant des coûts en termes de service non rendu et de charge de correction. Les besoins non satisfaits quant à eux induiront une perte d’énergie à rechercher des solutions alternatives pour combler les manques de l’application.
- les écarts non critiques révèlent une perte d’énergie dans la conception et la mise en place de fonctionnalités non utiles à la satisfaction des besoins, au détriment de la qualité de l’application, mais aussi de sa lisibilité et de son utilisabilité. Il pourra également en résulter une perte d’énergie dans l’appropriation de l’application par ses utilisateurs (« conformité inutile ») ou dans la compréhension de l’application lors des évolutions (« spécification inutile », non couverte par l’application réalisée et ne couvrant aucun besoin).
- La « conformité par hasard » quant à elle, peut être considérée comme une bombe à retardement dans la mesure où, portant sur des fonctions identifiées nulle part dans le dossier de conception, elle pourra induire des régressions inattendues lors d’évolutions futures de l’application.
Les zones de risque sont nombreuses. Sans un regard structuré et méthodique sur la question, il n’est pas possible de déterminer la part de chacune de ces zones ni l’importance des risques encourus.
Parler de risques induits par un logiciel, c’est poser en filigrane la question suivante : à quoi sert la qualité logicielle ? Est-ce un but en soi ou bien l’atteinte de la qualité remplit-elle un autre objectif ?
Faire de « la qualité pour la qualité » peut certes procurer de grandes satisfactions d’ordre esthétique, mais l’expérience a montré que le coût induit est alors exorbitant et sans grand rapport avec les enjeux portés par la mise en œuvre d’un logiciel, si critique soit-il pour l’entreprise.
De notre point de vue, la recherche de la qualité logicielle doit servir un objectif et un seul : la maîtrise des risques liés à l’utilisation du logiciel produit.
Le test, un moyen de couvrir plusieurs risques
Obtenir d’emblée le recouvrement des besoins exprimés, des spécifications de l’application et de l’application réalisée présuppose des conditions que les contraintes d’un projet permettent rarement d’atteindre.
Ces conditions sont notamment :
- une maîtrise complète du domaine métier et des interactions de l’application envisagée avec un système d’information de l’entreprise, lui-même exempt de failles conceptuelles et techniques ;
- des compétences techniques à leur meilleur niveau ;
- des délais et un budget compatibles avec la charge de travail et le dimensionnement des équipes ;
- une disponibilité optimale des intervenants ;
- une qualité maximale de la communication entre les différentes équipes en jeu.
Dans les faits, toutes ces conditions sont très rarement réunies dans un même projet. La qualité attendue ne pourra donc presque jamais être atteinte du premier coup.
Il faut alors envisager que tout ce qui sera produit au cours du projet devra être soumis à un contrôle destiné à vérifier le degré de convergence entre ce qui est projeté et ce qui est réalisé, afin d’obtenir, en bout de chaîne, la meilleure adéquation du logiciel produit aux attentes exprimées et implicites. Ce contrôle est le cœur même de l’activité de test, son objectif et sa raison d’être.
Pendant de nombreuses années, le test logiciel a été conçu et mis en œuvre en bout de chaîne, une fois que l’application était réalisée. De ce fait, les tests pratiqués étaient peu formalisés et portaient plus sur le produit fini dans son ensemble que sur les différents contenus, moyens et méthodes qui avaient abouti à sa réalisation.
Comme les tests étaient élaborés et mis en œuvre après les phases de réalisation, il n’était pas non plus rare que la charge et le délai consentis au test soient réduits à la portion congrue, du fait des dépassements occasionnés par les phases antérieures. Encore eût-il fallu que cette activité disposât d’un budget distinct et d’un délai incompressible, ce qui n’était pas toujours le cas, loin s’en faut. Nombreux ont été les projets dans lesquels le test a servi de variable d’ajustement en termes de coûts et de délais.
De plus, cette organisation des tests amenait inévitablement à une découverte tardive des anomalies, entraînant un coût de correction très élevé : sur une application déjà assemblée, le diagnostic d’une anomalie est complexe et tient parfois du pari, alors que la somme de corrections à apporter peut entraîner des effets de régression difficiles à maîtriser.
Le test était alors une activité plus empirique que rationnelle, qui servait plus à se rassurer qu’à attester d’un niveau de qualité défini, orienté vers la maîtrise des risques de défaillance du logiciel.
Depuis la fin des années 1990, le test tend à se structurer sur deux plans : en premier lieu, il n’est plus effectué en fin de projet, mais au terme de chacune des grandes phases de mise en œuvre du logiciel ; en second lieu, les pratiques sont formalisées en différents types de test, mieux définis et adaptés à chaque phase de la réalisation du projet (voir schéma ci-dessous).
La formalisation des types de test permet un travail plus structuré et plus méthodique, dans la mesure où l’on sait de façon précise ce qui est attendu des tests pratiqués, de quelle manière et à quel moment ils doivent être pratiqués et quels sont les risques qu’ils permettent de couvrir.
Leur mise en œuvre en parallèle des phases de réalisation favorise une détection des anomalies à la fois plus précoce et mieux ciblée. En retour, le diagnostic est plus simple, plus sûr et les corrections peuvent être effectuées de façon plus « chirurgicale », avec des risques de régression mieux maîtrisés.
Parmi les types de test les plus employés figurent :
- La revue de code, qui permet de s’assurer, au travers du respect des règles de codage des programmes, du degré d’attention porté à la réalisation d’un programme, mais aussi des risques de défaillance dus à un codage trop désinvolte ou trop complexe,
- Les tests unitaires qui permettent de s’assurer du bon fonctionnement et de la conformité de chaque composant de l’application pris isolément avant assemblage,
- Les tests d’intégration dont le but est de s’assurer du bon fonctionnement des échanges entre les différents composants de l’application (intégration applicative) ou de l’application concernée avec le reste du système d’information (intégration système),
- Les tests fonctionnels, destinés à vérifier la conformité de chaque fonctionnalité de l’application aux besoins et exigences qu’elle doit couvrir,
- Les tests de processus (tests de bout en bout), qui vérifient que le logiciel est en mesure de traiter un processus métier dans son entier, selon les règles du métier et en faisant appel, le cas échéant, à d’autres briques du système d’information,
- Les tests de performance et de charge, qui visent à garantir à la fois les délais de réponse du logiciel et le maintien de ces délais de réponses dans différents scénarios de sollicitation de l’application (tenue à la charge),
- Les tests de sécurité, qui permettent de s’assurer que le logiciel ne peut être utilisé que par les utilisateurs habilités et que son utilisation ne met pas en péril l’intégrité des données de l’entreprise.
A ceux-ci peuvent selon les cas s’ajouter d’autres types de test, tels que les tests d’accessibilité, d’installabilité, d’exploitabilité et de maintenabilité du logiciel.
Bien évidemment, la production d’un logiciel ne nécessite pas toujours la mise en œuvre de tous les types de test. La qualité attendue d’un logiciel se définit, on l’a vu, par la mise en évidence des risques que ce logiciel peut faire porter à l’entreprise. C’est à partir de la connaissance de ces risques que l’on décidera des types de test à mettre en œuvre.
D’autres facteurs entrent en jeu pour améliorer la qualité globale
La mise en œuvre de tout ou partie des types de test énumérés ci-dessus ne suffit pas à elle seule à garantir la qualité d’un logiciel. En effet, procéder à ces tests présuppose une application déjà spécifiée, conçue et, au moins en partie, réalisée.
S’en tenir à ces seuls tests équivaut donc à s’appuyer sans recul sur l’expression des besoins émis par les utilisateurs et sur la conception et la spécification du logiciel résultant de cette expression de besoins.
Dans le domaine des logiciels particulièrement, la « partie visible de l’iceberg » est l’application elle-même. Il est tentant de voir, dans les anomalies de fonctionnement constatées, des causes liées à la qualité des composants qui la constituent. C’est oublier un peu vite le soubassement, la « partie immergée », non visible a posteriori, qui recouvre l’expression des besoins et la phase de conception résultant de cette expression.
Lorsque l’on aborde cette partie immergée, deux questions se posent nécessairement :
- S’est-on assuré de la qualité de l’expression des besoins ?
- Peut-on garantir que la conception et la spécification du logiciel couvrent de façon satisfaisante les besoins exprimés ?
Tant qu’une réponse positive à ces deux questions n’est pas possible, le risque existe d’avoir dépensé beaucoup d’énergie pour un résultat inapproprié voire inutilisable.
La qualité d’un produit étant mesurée par le degré de conformité aux besoins, une défaillance dans l’expression des besoins a un impact immédiat et durable sur la qualité du logiciel produit. Plus important encore, cet impact n’est pas mesurable, du fait que l’expression des besoins est à la racine du projet et détermine les fonctionnalités de l’application et, par conséquent, le contenu de toutes les phases qui suivent. La conséquence de failles dans cette phase peut être une reprise extrêmement coûteuse du projet, voire son abandon pur et simple.
Les mêmes conséquences peuvent résulter de spécifications inadaptées aux besoins exprimés, alors même que les tests effectués en aval auront démontré une conformité satisfaisante à ces mêmes spécifications.
La qualité se prépare en amont…
L’importance des risques évoqués ici est à la mesure du poids de ces deux premières phases, qui structurent l’ensemble du projet et lui donnent ses orientations majeures. Une expression de besoin déficiente ou une conception inappropriée peuvent entraîner l’échec de l’ensemble du projet. Malheureusement, ces défaillances sont souvent découvertes trop tardivement, lorsqu’un changement de cap n’est plus possible.
Les types de test énoncés plus haut ne serviront donc pas à grand-chose sans un contrôle très précis des besoins émis et des spécifications réalisées.
La revue des besoins exprimés, de la conception et des spécifications qui en découlent apparaît comme une tâche majeure, un type de test très important qui doit être effectué dès le début du projet. De même, le contrôle de qualité doit débuter avec le projet et non en cours de projet. Plus tôt la qualité est prise en compte, meilleures seront les chances que le projet aboutisse et reste viable.
Et en aval !
Il faut aussi évoquer les risques de dysfonctionnement de l’application en aval du projet, durant sa période de production. En effet, quel que soit le soin mis à contrôler l’application dans ses moindres détails, nul ne peut prétendre maîtriser tous les effets induits par son utilisation répétée sur le long-terme. Trop de facteurs peuvent intervenir durant cette période, et tous ne peuvent être anticipés.
La qualité globale d’une application ne porte pas exclusivement sur ce qui précède la mise en production. Elle inclut aussi la garantie de son bon fonctionnement durant la période de production.
Pour ne prendre que l’exemple du maintien des performances d’une application, les conditions de son fonctionnement peuvent varier au cours du temps, induisant une évolution de son comportement non compatible avec les exigences initiales. Afin de pallier ce risque, la mise en place d’un suivi régulier des performances, basé sur les résultats des tests effectués avant la mise en production, permet d’anticiper des dysfonctionnements et de préparer des actions correctives adéquates.
Les tests menés dans la phase projet ne contribuent donc pas uniquement à la garantie de conformité initiale. Dans certains domaines, leurs résultats contribuent aussi à surveiller les dérives de comportement, à les analyser et à proposer des actions correctives, préparant ainsi la mise en place des versions suivantes.
Partant de là, la mise en œuvre d’un logiciel peut être découpée en trois phases, chacune avec des objectifs spécifiques et des moyens pour évaluer l’atteinte de ces objectifs :
– la phase amont,
– la phase de développement et d’intégration
– la phase de mise en production.
Objectifs et enjeux de la phase amont : valider les scénarios métiers
Comme dit précédemment, l’expression des besoins et la conception de l’application sont les étapes les plus structurantes du projet. Paradoxalement ce sont aussi celles qui, encore actuellement, sont le moins souvent assujetties à des contrôles de qualité.
Concernant l’expression des besoins, le contrôle de qualité visera essentiellement à s’assurer de la complétude des besoins et exigences exprimés, à la fois vis-à-vis du métier lui-même, mais aussi des interactions de ce métier avec les autres fonctions de l’entreprise. Pour ce faire, il faut vérifier que l’ensemble des scénarios métier sont pris en compte, et que chacun est formulé dans sa totalité, incluant aussi bien les opérations du métier lui-même que celles impliquant d’autres métiers, en amont et en aval de ces scénarios.
Cette exigence d’intégration aux autres fonctions de l’entreprise est d’autant plus importante à examiner que c’est un aspect souvent oublié, tant les intervenants métier sont souvent focalisés sur leurs seules activités. Ces dernières ne sont pourtant qu’une partie d’un enchaînement plus vaste, qui dépasse les limites de leur périmètre de responsabilité. De plus, il est important de s’assurer que toutes les exigences ont été explicitées et pas seulement les exigences fonctionnelles. Il s’agit notamment ici d’exigences en matière de performance, d’ergonomie, de sécurité, de disponibilité, etc. L’expérience montre là encore que des remises en cause très coûteuses peuvent avoir lieu en fin de projet, lorsque ces exigences n’ont pas été exprimées suffisamment tôt et de manière suffisamment précise.
Dans un deuxième temps, le contrôle de la conception applicative et des spécifications qui en découlent vise à s’assurer que sont prises en compte non seulement les exigences fonctionnelles, mais aussi les exigences non fonctionnelles. De plus, afin de garantir la meilleure intégration de l’application projetée au système d’information de l’entreprise, il faut aussi vérifier que l’application conçue s’intègre correctement dans le patrimoine applicatif existant, afin de prendre en compte l’ensemble des processus métier concernés, et en évitant de faire porter à l’application envisagée des fonctionnalités déjà existantes ou devant être portées par d’autres applications.
Si l’étape de conception applicative, en traduisant les besoins exprimés, permet souvent de détecter des insuffisances dans l’expression des besoins (inexactitudes, incohérences, imprécisions, etc.), seules les insuffisances portant sur le périmètre exprimé seront détectées. Si ce dernier est trop restreint par rapport à la réalité des besoins mais reste intrinsèquement cohérent, il y a fort peu de chances que toutes les insuffisances soient détectées.
Il n’est pas rare que plusieurs cycles « Expression de besoins – Conception » soient nécessaires avant que soit atteinte une cohérence satisfaisante entre ces deux maillons cruciaux du projet.
C’est le premier prix à payer pour une qualité satisfaisante du résultat. Mais il faut aussi ajouter deux considérations importantes : d’une part, ce prix est bien moins élevé que celui de la refonte d’une application en fin de projet et, d’autre part, il est encore moindre si l’on met en pratique une revue spécifique de l’expression des besoins avant de passer à la phase de conception.
Dans la pratique des tests qui tend à se généraliser, une stratégie de test est élaborée dès le début du projet, sur la base des besoins et exigences exprimés, ainsi que sur les exigences de la conception applicative. Cette stratégie permet de déterminer les différents types de tests qui devront être élaborés en fonction des caractéristiques de l’application et de la criticité des exigences émises et des contraintes qui pèsent sur elle. Cette phase préliminaire vise à cartographier le contrôle qualité qui sera mise en œuvre tout au long du projet et s’appuie sur les revues d’expression des besoins et de conception applicative.
Objectifs et enjeux des phases de développement et d’intégration : le contrôle qualité
Les phases de mise en œuvre proprement dite du projet sont celles qui, actuellement, sont le plus souvent et le plus systématiquement assujetties au contrôle qualité.
Afin de s’assurer d’une qualité satisfaisante de l’application, de nombreux tests doivent être effectués aux différents stades de la mise en œuvre de l’application. Chaque stade fait appel à des types de tests spécifiques :
- Au premier stade, celui du codage des composants, la mise en œuvre de tests unitaires permettra de s’assurer de la conformité de chaque composant indépendamment des autres. Ces tests unitaires sont de plus en plus souvent conçus en même temps que le composant lui-même et automatisés, ce qui permet un gain de temps appréciable. Les revues de code sont un autre type de test, de plus en plus pratiqué depuis que l’on a découvert une corrélation positive entre le respect des normes de codage, la simplicité du code et la qualité du composant ainsi codé. Des outils permettent de systématiser ce travail de revue de code.
- L’assemblage du code en unités applicatives plus importantes peut être une source d’anomalies importante lorsque les composants n’échangent pas correctement des informations entre eux. Les tests d’intégration permettent de s’assurer du bon fonctionnement de ces assemblages et de la conformité des échanges entre les composants qui le constituent.
Les tests qui précèdent visent une conformité technique des composants réalisés et assemblés. Ils sont certes nécessaires, mais absolument pas suffisants, dans la mesure où ils ne sauraient garantir que les fonctionnalités réalisées sont conformes à leurs spécifications, aux besoins émis et qu’elles couvrent l’ensemble de ces besoins.
- Le contrôle de cette conformité est le rôle des tests fonctionnels, qui succèdent aux tests d’intégration et portent sur chacune des fonctionnalités de l’application, indépendamment les unes des autres.
- Parallèlement aux tests fonctionnels et parfois aux tests unitaires, la mise en œuvre de tests de performance sur des composants ou des fonctionnalités permet de détecter et de résoudre précocement d’éventuels problèmes de performance, avant de mener des tests de performance sur l’ensemble de l’application.
- Enfin, ce n’est pas parce qu’une application, prise indépendamment du patrimoine applicatif de l’entreprise, donne toute satisfaction, qu’il en sera de même lorsqu’elle aura été intégrée au système d’information de l’entreprise. Les questions à ce sujet sont nombreuses et vitales pour l’ensemble de l’entreprise. En particulier :
- L’application pourra-t-elle assurer la liaison avec les autres applications, internes ou externes à l’entreprise, avec lesquelles elle doit interagir ?
- Quel sera l’impact sur ses performances d’une sollicitation simultanée par un nombre important d’utilisateurs ?
- Quel sera l’impact de son fonctionnement sur celui du système de l’entreprise et cet impact sera-t-il acceptable ?
- Les procédures liées à son installation et à son exploitation répondront-elles aux normes applicables ?
- Présente-t-elle un risque pour la sécurité de l’entreprise ?
Afin de répondre à toutes ces questions et ainsi de garantir l’innocuité de la mise en œuvre d’une application dans le système de l’entreprise, de nombreux tests devront être mis en œuvre : tests de bout en bout, tests de charge, tests de sécurité, d’installabilité et d’exploitabilité, pour ne citer que les plus courants.
Les scénarios mis en œuvre au cours des tests devront aussi vérifier que l’ensemble du système d’information n’est pas impacté par l’immersion de la nouvelle application dans son contexte.
Les nombreux types de test évoqués plus haut permettent la détection des défauts de l’application (ou « anomalies »). On ne saurait se contenter de détecter ces défauts. Il convient bien évidemment de les corriger au plus tôt. Or, toute correction peut entraîner à son tour des anomalies, principalement pour deux raisons : soit la correction apportée présente des défauts en elle-même, soit elle révèle des défauts dans d’autres parties de l’application non modifiées par la correction apportée. Les anomalies relevant de cette deuxième cause sont appelées des régressions.
Dans une optique de garantie de qualité, il est donc nécessaire, à la suite d’une correction, de procéder à deux tests distincts : le test de la conformité de la correction apportée et celui de la non régression du reste de l’application. Selon le niveau de l’anomalie corrigée, le champ des tests de non régression sera plus ou moins étendu.
Les tests pratiqués lors de la mise en œuvre nécessitent un degré de synchronisation très élevé avec les phases de cette mise en œuvre. Cela a un impact très fort sur l’organisation du projet qui doit paralléliser les différentes phases de mise en œuvre avec les tests concomitants.
Le test est un donc bien un projet à part entière, à mener en parallèle du projet de réalisation. Il doit exister de nombreux points d’articulation entre les phases de mise en œuvre et celles des tests.
Durant chaque phase de test, il faut enregistrer les tests effectués, les résultats obtenus, les anomalies détectées et suivre la correction de ces dernières. Ces enregistrements permettent de mesurer l’avancement du projet (quantité de tests effectués ou couverture) ainsi que la qualité de l’application testée (quantité, gravité et statut des anomalies détectées).
La fin d’une phase de test est déclarée lorsque les critères d’arrêt des tests sont satisfaits : le taux de couverture des tests est atteint, le nombre d’anomalies non corrigées n’est pas dépassé. Les valeurs de ces critères sont déterminées en début de projet, et déclinées pour chaque phase de test.
Il en va de même pour la fin de projet de test lui-même, au moment de la décision de mettre l’application en production. Ces critères d’arrêt constituent une base objective, capitale pour la décision de mise en production.
Objectifs et enjeux après la mise en production : surveiller les performances
Quel que soit le soin apporté à contrôler la qualité de l’application, rien ne permet d’affirmer qu’aucune défaillance ne surviendra par la suite.
C’est particulièrement le cas des performances pour les applications ou les services fortement sollicités par des utilisateurs ou d’autres services. Dans ce domaine, la surveillance des performances a pour but de s’assurer que les exigences de performance assignée à l’application sont respectées et d’être en mesure de prévenir les dégradations trop importantes, ou du moins d’y réagir au plus tôt.
Ceci peut être réalisé par la mise en place d’un dispositif de sondes permettant d’enregistrer en temps réels les indicateurs de performance retenus et, par confrontation à des seuils définis, d’alerter sur le dépassement potentiel ou avéré de ces seuils.
Les informations obtenues lors des tests de performance peuvent contribuer largement à la définition des indicateurs à sonder et des seuils d’acceptabilité.
En retour, les données collectées par le dispositif de surveillance permettent d’avoir une idée concrète et précise de la performance en production, en fonction de la sollicitation effective de l’application. Elles permettent aussi d’avoir une idée précise des conditions de cette sollicitation et de ses variations.
Une telle connaissance permettra une meilleure anticipation des défauts de performance, une meilleure prévention en production et la préparation d’actions correctives en profondeur pour optimiser les versions suivantes de l’application.
Ce principe de surveillance se met actuellement en place dans le domaine du suivi des performances (APM ou « Application Performance Monitoring« ).
Le même principe est déjà mis en œuvre dans d’autres domaines. C’est notamment le cas des enquêtes de satisfaction, qui se multiplient depuis plusieurs années et qui contribuent aux évolutions fonctionnelles et ergonomiques des applications.
Le processus qualité ne s’arrête donc pas avec la mise en production. A ce moment particulier du cycle de vie de l’application, seul change le moyen mis en œuvre pour garantir un niveau de qualité. Avant la mise en production, c’est le test, qui confronte une réalisation à des exigences émises sur le papier. Après la mise en production le test est remplacé par la mesure. Confrontée aux exigences initiales, celle-ci favorise la prévention des défaillances et permet en retour une révision de ces exigences, affinées par la réalité mesurée sur le terrain.
Lorsqu’un incident se produit malgré tout, la précision et la richesse du constat fournissent aussi des informations précieuses pour réviser les exigences émises au départ.
Le coût de la qualité
Longtemps, le test informatique a été considéré comme une activité coûteuse, en particulier dans le domaine de l’informatique de gestion. Coûteuse donc trop coûteuse, car considérée comme sans réelle valeur ajoutée directe.
Une telle perception du test s’enracine à la fois dans une conception très marchande de l’activité humaine, qui donne de la valeur au produit consommable, et dans l’histoire de l’informatique, qui a longtemps considéré la défaillance des applications comme un mal nécessaire mais présentant peu de risques.
Le test, un centre de coût
Selon les critères de profitabilité d’une entreprise, le développement informatique produit de la valeur ajoutée en étendant les possibilités de l’entreprise, en remplaçant de coûteux postes de travail humains par des automates plus fiables, moins coûteux et au comportement très prévisible (en apparence), ou dans certains cas, en permettant de tirer bénéfice de la vente d’applications pouvant être dupliquées à l’infini.
Au regard de ces mêmes critères, le test, lui, ne produit rien d’autre que l’affirmation d’avoir contrôlé le bon fonctionnement de l’application, traces à l’appui dans le meilleur des cas. Et ce simple contrôle peut coûter jusqu’à 40 ou 50 % du budget total et nécessiter des équipes très spécialisées. Avec en prime la certitude de dépenser encore plus en tests supplémentaires lorsque l’on procèdera à des évolutions ou des adaptations de l’application.
Là où le développement informatique peut devenir un centre de profit dès lors que l’on peut monnayer sa production, le test reste désespérément un centre de coût. Tout au plus pourra-t-il éviter des pertes, mais est-on bien certain que le jeu en vaut la chandelle ? Car enfin, qu’est-ce qui prouve que l’application présente des défaillances ? A priori, rien. Du moins tant qu’elle n’a pas été sortie de sa boite et expérimentée.
Vue sous cet angle, la valeur d’investissement du test est difficile à argumenter.
A ses débuts et jusqu’à la fin des années 1980, la principale valeur ajoutée de l’informatique de gestion était la rationalisation des coûts du travail, remplaçant par des automatismes un travail répétitif effectué auparavant par des employés. L’objectif premier était la diminution du nombre de postes de travail. Cette informatique-là avait une forte dimension d’organisation.
Une attitude réactive
Les services rendus par l’informatique étaient alors très localisés et les différentes fonctionnalités rarement interconnectées. Le recours aux applications informatiques était une activité plutôt annexe et peu d’applications se trouvaient sur le chemin critique des processus de l’entreprise. Comme tout ne reposait pas sur l’informatique, la défaillance d’une application était souvent sans impact majeur sur l’activité et sur les autres applications. L’informatique de l’époque n’était pas perçue comme porteuse d’un risque significatif pour l’entreprise.
Dans un tel contexte, le comportement vis-à-vis des défaillances informatiques était plus réactif que proactif : le constat de défaillance entraînait des corrections, considérées comme plus ou moins urgentes, et l’on se posait rarement la question de l’anticipation des défaillances.
Progressivement, avec les possibilités offertes en matière d’interopérabilité des systèmes, l’informatique a irrigué l’ensemble des activités de l’entreprise, au travers de systèmes d’information intégrés, dans lesquels les fonctionnalités sont devenues de plus en plus interdépendantes, transformant peu à peu le système d’information en centre névralgique de l’entreprise.
Ainsi, les mêmes fonctionnalités qui, prises isolément, étaient considérées comme peu critiques, du simple fait de leur implication dans un système plus complexe, sont devenues porteuses de risques plus importants, à l’échelle de la criticité du système dans son entier.
Dans des secteurs comme la banque, la finance ou les assurances, le système d’information est devenu le principal moteur de la production quotidienne, et certaines de ses défaillances peuvent entraîner des conséquences majeures voire catastrophiques pour l’ensemble de l’entreprise.
Ces dernières années ont aussi été marquées par une progression importante des échanges de données informatisées en temps réel entre l’entreprise et le monde extérieur (partenaires, services publics, etc.). L’interdépendance s’est ainsi élargie, renforçant au passage la contrainte de disponibilité des systèmes et applications. La moindre défaillance peut alors avoir des impacts colossaux, entraînant des pertes qui peuvent se chiffrer en millions voire en milliards d’euros.
Petit à petit, l’informatique est en train de devenir, comme l’électricité, un « fluide » fonctionnel et informationnel vital pour l’entreprise.
Les défaillances applicatives, de plus en plus visibles
Dès lors que l’essentiel de l’activité repose sur le système d’information, une défaillance applicative parfois minime peut avoir des répercussions très importantes en aval, non seulement pour l’entreprise elle-même, mais aussi parfois pour ses partenaires.
Enfin, depuis une dizaine d’années environ, le client particulier est lui-même devenu opérateur de certaines fonctions de l’entreprise : achats en ligne, banque à distance, réservation de voyages, déclaration de revenus en ligne, etc. Cette évolution des pratiques non seulement augmente encore la contrainte de disponibilité des systèmes d’information, mais elle impose de plus une très forte tolérance à la sollicitation massive : lorsque plusieurs millions de contribuables se précipitent sur leur ordinateur pour déclarer leurs revenus au dernier moment, il n’est pas envisageable que l’application de déclaration en ligne défaille pour cause de trop forte sollicitation ; elle doit fonctionner de façon aussi satisfaisante avec plusieurs millions d’utilisateurs simultanés qu’avec quelques centaines.
Les attentes sont telles aujourd’hui vis-à-vis des systèmes d’information qu’il n’est plus possible de se contenter d’un comportement purement réactif face aux défaillances informatiques : réparer ne suffit plus, car cela prend trop de temps et peut entraîner d’autres défaillances, surtout quand cela est fait dans l’urgence. Il faut anticiper les défaillances, afin d’éviter leurs conséquences parfois incalculables.
Dès lors, la question du coût de la qualité devient secondaire face à celle du coût de la non qualité.
Les mentalités et les schémas de pensée évoluent moins vite que les possibilités techniques et les transformations qu’elles entraînent. Souvent, ce constat vient du fait que ces évolutions se sont faites sans toujours procéder d’une vision globale définie a priori. Ainsi, c’est souvent par le constat parfois cruellement coûteux de l’impact de certaines défaillances que les entreprises ont pris conscience de la notion de risque informatique et de la nécessité d’anticiper ce risque, un exemple très parlant à ce titre étant celui du « bug de l’an 2000 ».
La question du retour sur investissement
En matière de coût, la question souvent été posée est celle du retour sur investissement. Celle-ci oppose le coût du test préalable à celui de la correction a posteriori des incidents survenus en production.
La réponse ne va pas de soi, pour deux raisons :
- D’abord car le coût des corrections est rarement extériorisé en tant que tel. Il est souvent fondu dans des activités de suivi de production ou de développement qui ne permettent pas de l’associer aux incidents en tant que tels. De ce fait, une comparaison n’est pas possible.
- Ensuite et surtout, même si l’on pouvait connaître le coût de correction incident par incident, la comparaison n’aurait pas grand sens, car ce serait faire abstraction de coûts parfois beaucoup plus importants, qui ne relèvent pas uniquement du budget de l’informatique : il s’agit des coûts induits par la défaillance elle-même : pertes dues à la défaillance ou induites par l’indisponibilité du système consécutive à la défaillance, coûts de mise en place d’une solution alternative temporaire, coûts induits par la désorganisation partielle des services concernés. Enfin, une fois la correction apportée, il faudra réintégrer dans le système les opérations effectuées grâce à la solution alternative mise en place.
A titre d’exemple, la panne du réseau Orange en juillet 2012, due à un défaut logiciel, représente un coût évalué à 30 millions d’euros par le PDG d’Orange alors qu’elle n’a duré « que » douze heures environ. Difficile d’imaginer qu’une correction de logiciel puisse coûter une telle somme. Difficile aussi d’imaginer de tels coûts pour tester un logiciel avant la mise en production.
Néanmoins, ces exemples montrent bien que la qualité n’est pas un produit en soi, mais un attribut du produit qu’elle contrôle et qui en garantit les caractéristiques « vertueuses » : utilisabilité, conformité, pérennité, non-toxicité, etc.
Schématiquement, le retour sur investissement d’un produit évalue l’ensemble des coûts de production, de promotion et de vente de ce produit et oppose à ces coûts une valorisation des bénéfices par unité de produit vendu. En estimant un volume de vente par unité de temps, on peut en déduire le temps qu’il faudra pour amortir les coûts et commencer à faire du profit.
Cette approche permet certainement d’argumenter l’opportunité d’un investissement. Cependant, elle considère une situation « idéale », dans laquelle le produit vendu donnera toute satisfaction. Elle ne tient aucun compte des coûts induits par les dysfonctionnements potentiels du produit, qui sont le coût de la non qualité.
La question n’est donc pas celle du retour sur investissement, parce que la qualité, n’étant pas un produit, ne saurait représenter un investissement distinct de celui du produit. Le coût de la qualité constitue une part de l’investissement dans le produit. Cette part consentie donne en retour un niveau de garantie sur les marges envisagées, du fait que ces dernières ne seront pas consumées par les effets résultant d’incidents de fonctionnement.
Seul le coût de la non-qualité peut être opposé au coût de la qualité.
En revanche, si l’on souhaite avoir une idée de l’impact de la mise en œuvre d’un processus qualité sur le comportement des applications, il est relativement simple de procéder à des comparaisons entre applications sur la base de mesure des incidents par tranches de temps (semaine ou mois par exemple).
Les mesures pourront être le nombre d’incidents, la durée moyenne d’indisponibilité de l’application, le coût de correction des incidents de la période. En corrélant ces mesures avec la part consentie aux tests dans le budget de mise en œuvre, il est possible de se faire une idée assez précise de l’impact du test sur le bon fonctionnement des applications.
Une telle évaluation impose toutefois un suivi très détaillé et très rigoureux des mesures retenues, sur l’ensemble du parc applicatif de l’entreprise et au long cours.
Rendre le coût des tests acceptable
Les coûts induits par les défaillances sont très rarement anticipés. Ils ne sont pas non plus supportés par le budget du projet informatique qui est à l’origine de l’application défaillante. Ceci explique peut-être pourquoi la qualité continue parfois d’être perçue comme trop coûteuse lors de l’élaboration du budget du projet.
En revanche, dès que l’on se penche sur les risques potentiels que des défaillances peuvent faire courir, non au projet, mais à l’entreprise elle-même, il devient possible de faire une évaluation a priori du risque et de son coût. A ce titre, l’analyse du risque applicatif est une des composantes de la première étape d’un projet de test. Si elle ne permet pas à elle seule d’évaluer le coût potentiel des défaillances, elle permet de situer la criticité des fonctionnalités, d’orienter les priorités du test afin de porter l’effort sur les composants dont les défaillances potentielles auraient les effets les plus graves.
Par ailleurs, le test s’étant fortement structuré et professionnalisé, il est désormais possible de procéder à une estimation de son coût, d’extérioriser ce coût et de le confronter à la fois au budget global du projet et au coût estimé de la non qualité de l’application. De plus, la justification du coût estimé des tests donne aussi une visibilité sur ce qui sera testé et comment cela sera fait.
Dès lors, le test devient une activité lisible, argumentée et structurée. Son coût rapporté au budget global du projet peut être opposé au coût estimé de la non qualité et il devient possible d’en arbitrer certains postes en connaissance de cause, c’est-à-dire en fonction des risques.
De trop élevé, souvent par manque de visibilité, le coût de la qualité devient alors acceptable.
Maîtriser et optimiser les coûts du test
Le coût réel du test, observé en fin de projet, peut être très différent de ce qui avait été estimé en début de projet. Cela tient à des facteurs non mesurables a priori, qui sont le nombre et la gravité des anomalies qui seront détectées, ainsi que la qualité des corrections qui seront apportées.
Ce constat peut conduire à un certain vertige budgétaire, où là encore, le test est perçu comme un coût décidément non maîtrisable. Or, ici encore, ce sont les conséquences de la non-qualité effective qui sont coûteuses, plus que l’évaluation de la qualité par le test.
Comment, avec de telles prémisses, ne pas tomber dans le tonneau sans fond des Danaïdes, et faire en sorte de rester dans les limites de l’estimation initiale ?
Il est évident que, si l’objectif est que l’application soit 100 % « bug free », le pari est rarement tenable. Ce pari sera d’autant moins tenable que l’application concernée fera partie d’un système plus complexe. En effet, si une application peut occasionner des pannes par ses propres défaillances, son immersion dans le système d’information peut aussi révéler des défaillances latentes de ce dernier.
La sensation de vertige persiste, voire s’amplifie.
La maîtrise de ce risque portant à la fois sur le budget du projet et sur son succès passe par la mise en pratique d’un principe qui, sans prétendre à une couverture absolue du risque, donne souvent de bons résultats.
Différencier les défaillances
Ce principe repose sur le constat que toutes les défaillances n’ont pas la même gravité pour l’entreprise : certaines n’entraînent que peu de perturbations, d’autres localisent ces perturbations dans un périmètre non critique pour l’entreprise, ce qui les rend supportables même si elles sont à bon droit perçues comme gênantes. En revanche, d’autres sont, comme on l’a vu, totalement non supportables de par les conséquences qu’elles entraînent pour l’entreprise.
Il n’est donc, de ce point de vue, pas absolument indispensable de tout tester et de corriger toutes les anomalies détectées. En revanche, il est indispensable de s’assurer de la conformité de l’application aux exigences les plus critiques, afin de limiter le risque pour l’entreprise.
Pour cela, il est indispensable que soient explicitées précisément toutes les exigences de l’entreprise vis-à-vis de l’application et de son intégration dans le système d’information. Ces exigences doivent faire l’objet d’une analyse de risque, afin de déterminer leur poids dans le risque global. Nous parlons ici aussi bien d’exigences fonctionnelles que non fonctionnelles (sécurité, performances, disponibilité…).
Ensuite, la stratégie de test de l’application doit déterminer la contribution de chaque part de l’application aux différentes exigences explicitées. Ceci permettra de déterminer un facteur structurant du projet de test, à savoir la priorité à donner aux différentes parties à tester et aux différents types de test à effectuer.
Privilégier une gestion par niveaux
Lors de l’estimation du budget du test, la totalité des tests envisagés doit être prise en compte. En revanche, la connaissance des priorités de test permettra de définir des niveaux (en général trois) d’importance de ces tests. Cette gestion par niveau permet d’éviter bien des difficultés, les niveaux les moins critiques jouant le rôle de variable d’ajustement du projet de test en termes de gestion du budget et des délais.
Dans de nombreux cas, cette méthode suffit à ne pas dépasser les limites de départ. Dans tous les cas, elle permet de déterminer en connaissance de cause les rallonges budgétaires et de délai à consentir le cas échéant.
La mise en pratique de cette méthode a trois effets vertueux :
- Le premier est que, si toutes les anomalies détectées par le test ne sont pas corrigées pour des raisons de priorités, du moins elles sont identifiées et l’on connaît de façon plus précise le degré de qualité de l’application au moment de la mise en production.
- Ensuite, si tous les tests n’ont pu être effectués, les parties à risque de l’application sont connues et, combiné à ce qui précède, cela permet la mise en place d’une surveillance ciblée de l’application en production.
- Enfin, et peut être le plus important, l’identification a priori des parts les plus risquées de l’application permet aux équipes de mise en œuvre de différencier l’effort et les ressources affectées en fonction de la criticité des composants à réaliser. Partant, cela peut diminuer fortement les anomalies et contribuer à une fiabilisation du projet « à la source ».
Là encore, les effets induits de la mise en pratique de ce principe de priorisation sont fortement liés à un autre principe déjà évoqué : plus tôt la question de la qualité sera prise en compte, plus on a de chances d’une qualité acceptable et au meilleur coût.