L’intérêt d’un référentiel de test – Arnaud Verin

Cet article est un peu long, mais le sujet le nécessite pour être pleinement traité.

Si vous connaissez déjà le sujet où que vous manquez de temps, je vous propose dans un premier temps de ne lire que la fin, à partir du chapitre « Solution intermédiaire ». C’est à partir de là qu’est abordé la solution la plus innovante en termes de gestion de référentiel de test.

Le projet de tests

On entend souvent dire que les tests coûtent cher. C’est même un des principaux freins à leur mise en place ou à l’arbitrage d’un périmètre de test. On considère que les tests seront faits en production pour un coût moindre, sans tenir compte du coût de la non qualité.

L’évaluation économique du coût de la non qualité par rapport au coût de la qualité est souvent difficile à effectuer. Le coût de la non qualité est pas ou mal évalué, ce qui participe au constat précédent. Alors que dans le cadre d’un processus de test efficient, le coût de la qualité pour une anomalie est nécessairement inférieur au coût de la non qualité pour cette même anomalie. Par contre ces coûts ne sont pas toujours gérés au même niveau, le coût de la qualité niveau projet, le coût de la non qualité au niveau organisation.

Malheureusement, souvent le critère déclencheur de la mise en place d’une démarche structurée de test est la survenue d’une anomalie critique en production ayant de graves conséquences.

Mais au-delà de l’estimation du coût de la non qualité pour évaluer la plus-value des tests, des marges de manœuvre existent sur le coût de la qualité, notamment autour des aspects de gestion du référentiel de test.

Afin de se rendre compte du coût des tests, analysons la structuration des activités de tests et leurs intérêts.

Structuration des activités de tests

Les activités de test se répartissent entre l’organisation des tests, la conception des tests, la spécification du référentiel de test et l’exécution des tests (hors clôture des tests). Chacune de ces phases consistant en un certain nombre de tâches :

• Organisation des tests : elle sert à définir la meilleure manière de tester la solution en tenant compte des différentes contraintes existantes. Elle répartit l’effort de test entre les différents protagonistes, et organise d’un point de vue stratégique et logistique chacun des niveaux de test. Elle se décline dans des documents de stratégie et plan de test.
• Conception des tests : en fonction de la stratégie particulière d’un niveau de test et à l’aide d’un certain nombre de technique, elle définit les exigences de test ou cas de test qui seront exécutés afin de vérifier la solution.

Historiquement, ce travail donnait lieu à l’identification de cas de test à l’intérieur du plan de test. L’arrivée des outils de référencement des tests actuels a galvaudé le terme de cas de test, puisqu’il s’agit pour eux d’un composant réutilisable qui sera instancié dans un scénario au travers d’un jeu de données et d’un contexte d’exécution, et qu’on nommera ici procédure de test pour éviter la confusion.

(De la même manière on parlera d’exigences de test au lieu de cas de test dans la suite de l’article, pour éviter toute confusion, même si les termes ne sont pas exactement équivalents)

• Spécification du référentiel de test : elle permet de créer un ensemble d’instructions à suivre afin de tester la solution. Le référentiel de test est composé d’un ensemble cohérent de scénarios, procédures et pas de test décrivant les différents fonctionnements applicatifs.
• Exécution des tests : elle permet le passage des cas de test sur la solution livrée par le fournisseur, dans le but de se rendre compte de son état de fonctionnement. Ceci induit l’ouverture des anomalies découvertes, leurs suivis ainsi que la gestion des patchs correctifs.

Répartition des activités de test

Dans les projets de test, souvent les premières phases sont peu ou pas faites et seule l’exécution est effectuée bon an, mal an. L’exécution étant sur le chemin critique du projet, tout aléa aura un impact majeur sur les coûts et délais du projet.

Les phases d’organisation et de conception des tests permettent de maitriser la couverture de test, de contenir le périmètre des tests et de maitriser le déroulement de la phase d’exécution et donc les coûts et délais globaux des tests. Il faut rapprocher un projet de test d’un projet de développement, pour lequel les phases d’organisation et de conception sont essentielles. Ces deux phases permettent de la même manière que pour le test, de maitriser le planning de développement et de contenir et maitriser le contenu de la solution à venir. Donc avec l’exécution des tests, ces deux phases préparatoires sont obligatoires afin de bien gérer les tests, et leur coût est négligeable comparé au service rendu.De plus celles-ci n’étant pas sur le chemin critique du projet, tout report d’activités de l’exécution vers elles, aura un effet immédiat sur le délai global du projet.

La dernière phase, que nous n’avons pas encore abordée, est la spécification du référentiel de test. Les exigences de test étant définies, il s’agit maintenant d’écrire toutes les procédures correspondant à ces exigences, et l’ensemble des résultats que nous attendons de la part de l’applicatif. Cette démarche doit être minutieuse afin de garantir l’exhaustivité des actions et réponses attendus, et ainsi avoir une plus-value par rapport aux exigences de test. Cette phase représente donc un coût non négligeable d’écriture.

Souvent on observe des référentiels de test mal structurés ou décrits et qui ne sont au final pas utilisable et maintenable. Au vu de son coût, quel est l’intérêt réel d’un référentiel de test, et dans quel cas doit-on en mettre un en place ?

Intérêt d’un référentiel de test

Un référentiel de test est l’ensemble des scénarios, procédures et pas de test permettant de vérifier la qualité d’un système logiciel. Il sert de ligne directrice durant l’exécution des tests, afin de savoir les actions qu’il faut réaliser et le comportement attendu en retour de l’applicatif. Le coût estimatif de mise en place d’un tel référentiel est en général de 40% du coût des tests, soit environ 9% du coût d’un projet (les études rapportent un ratio de 20% à 25% de coût de test pour un projet). Il s’agit donc d’un investissement non négligeable qu’il faut engager après vérification de son intérêt.

Éléments de plus-value d’un référentiel de test

Quel est donc l’intérêt d’un tel référentiel de test :

Si le référentiel est bien décrit avec l’ensemble des actions à réaliser et l’ensemble des résultats attendus, on sera certain à chaque instant que le comportement de l’applicatif correspond à ce que l’on souhaite. Les testeurs auront confiance dans le référentiel de test et ceci se ressentira sur la qualité du travail.

Souvent on rencontre des testeurs, qui en exécutant des tests imprécis se disent que le comportement survenu doit peut être correspondre, et ne déclarent donc pas les anomalies constatées et inversement, ou les décrivent mal.

Avec un bon référentiel, on n’aura pas besoin d’investiguer outre mesure, chaque comportement anormal observé sera considéré comme une anomalie. Les anomalies découvertes seront effectives ce qui entrainera des gains dans les relations avec les équipes de développement, ainsi que des gains en terme de coût par la baisse du volume des discussions entre les équipes de développement et de test. De plus, aucunes anomalies qui auraient dû être découvertes par la couverture de test, ne passera au travers des mailles du filet.

Souvent durant la phase d’exécution des tests, on voit les équipes de test se replonger dans les spécifications fonctionnelles afin de vérifier les actions à mener ou le comportement réel attendu de la part de l’applicatif. Or, la phase d’exécution des tests se situe sur le chemin critique projet alors que la phase de spécification du référentiel de test ne l’est pas. Donc si le référentiel est bien décrit et qu’il n’est pas nécessaire de se replonger dans les spécifications fonctionnelles durant la phase d’exécution des tests, on aura un gain immédiat sur le délai global du projet.

Avec un référentiel de test exhaustif, on est en mesure de remplacer au pied levé un testeur qui aurait une indisponibilité. Il s’agit donc aussi d’une gestion de risque dans des cas de forces majeures qui nécessiteraient à un testeur de poursuivre l’exécution des tests effectuée par un autre.

L’exécution des tests est une période dans laquelle la gestion des risques est un élément primordial afin de se prémunir des divers aléas. Il faut se dégager le plus possible de la prééminence de ressources irremplaçables. Pour atteindre cet objectif, le référentiel de test doit être couplé à une gestion efficace et centralisée des données de test.

On observe assez fréquemment des équipes de test qui ont dû réécrire entièrement le référentiel de test, car elles ont été incapables de repartir de celui fait par l’équipe projet précédente. Elles ne s’y retrouvaient pas dans la structuration de celui-ci, elles ne comprenaient pas la logique d’assemblage des différents éléments du référentiel ou alors elles n’arrivaient pas à relire les pas de test. Le projet paye donc à la fois pour le référentiel de test des évolutions en cours et pour le référentiel de non régression par rapport à la version précédente. Ceci a pour conséquence de faire augmenter le coût des tests d’une version à l’autre avec l’augmentation du périmètre applicatif.

L’intérêt d’un bon référentiel de test est bien évidemment d’être compréhensible et réutilisable par un maximum de personnes possibles. Il doit être bien structuré suivant une logique fonctionnelle partagée, il doit être clair, exhaustif et souffrir d’aucune ambigüité. On aura alors un gain sous forme de coût par la réutilisation effective du référentiel de test de la version précédente.

Un autre intérêt d’un référentiel de test de qualité est son automatisation sans autre intervention que celle d’un automaticien. Il n’aura pas besoin de compétences fonctionnelles particulières et son travail s’apparente à un projet de développement, et à la meilleure structuration du référentiel de l’automate afin qu’il soit maintenable et réutilisable d’une version sur l’autre.

Pour atteindre cet objectif et de la même manière que pour le point précédent, le référentiel de test doit être sans ambigüité et surtout exhaustif, étant donné que l’automate n’a pas droit à l’erreur. On peut considérer l’automate comme la moins intelligente des personnes, puisqu’il ne fera les actions et ne contrôlera que ce qu’on lui aura demandé de faire. Le but d’un automate étant de pouvoir s’exécuter sans aucune intervention humaine, il devra donc être robuste et maitriser le déroulement de l’exécution.

Le gain de l’automatisation d’un bon référentiel est double : pas besoin de refaire la spécification du référentiel de test manuel, comme c’est souvent le cas, puisque celui-ci est de qualité ; les phases de debugging de l’automate seront réduites dû à la robustesse du référentiel ayant servi comme point de départ à l’automatisation.

Un référentiel de test est avant tout un capital qui se transmet d’une version à l’autre de l’application. Les scénarios de test représentent donc une certaine expertise de l’application qui peut notamment servir à des tâches de formation et de montée en compétence de nouvelles ressources, et pas seulement des ressources de test.

D’où l’importance de la participation du métier à la construction du référentiel de test : à la fois pour avoir une couverture de test répondant au mieux à l’utilisation réelle de l’application sur le terrain ; à la fois pour construire un capital des processus métier.

Conditions permettant d’obtenir une plus-value du référentiel de test

Il y a donc un réel intérêt à mettre en place un référentiel de test. Mais comme nous venons de le voir, afin d’obtenir des résultats justifiants d’un retour sur investissement, le référentiel de test devra être bien structuré suivant une granularité adéquate à l’utilisation, la maintenabilité et à la bonne automatisation de celui-ci.

On voit donc que dans ce cas bien précis, le référentiel de test représente une réelle plus-value par rapport à la seule description des exigences de test. Mais pour atteindre ce résultat, il faut posséder un certain nombre de connaissances et de compétences qui milite vers la professionnalisation du métier de testeur.

Si on n’atteint pas ce niveau de structuration et de description du référentiel, ces intérêts ne sont plus présents et le référentiel devient un coût sans retour d’investissement.

Intérêt annexe à la mise en place d’un référentiel structuré

Un autre intérêt lié à la mise en place d’un référentiel de test et à la mise en place d’équipes dédiées aux tests qui lui est fortement intriqué, est le recentrage des experts sur le métier opérationnel de l’organisation. Effectivement, actuellement la plupart des concepteurs fonctionnels font aussi de la recette. La professionnalisation du métier de testeur permet donc de libérer du temps sur les concepteurs fonctionnels pour qu’ils se concentrent sur des tâches ayant une plus grande valeur ajoutée par rapport à leurs compétences et connaissances.

Retour sur investissement d’un référentiel de test

On parle souvent du retour sur investissement de l’automatisation, mais rarement de celui du référentiel de test manuel. Et pourtant la problématique est la même, la réutilisabilité et la maintenabilité d’un référentiel. La seule différence est que le référentiel manuel de test est sous forme textuelle alors que le référentiel de l’automate est sous forme d’instruction logicielle. Mais ces instructions ne sont que la traduction en langage informatique des instructions littérales du référentiel de test.

Il en découle que le coût d’un référentiel d’automate sera supérieur à celui d’un référentiel de test manuel, étant donné qu’il est plus long de coder et de débugger que d’écrire un texte. Le retour sur investissement d’un référentiel de test manuel est donc meilleur que celui d’un référentiel d’automate. Donc pour le même périmètre applicatif il est plus évident de construire un référentiel de test manuel qu’un référentiel d’automate. Néanmoins les deux nécessitent une étude pour évaluer leur retour sur investissement.

Critères de retour sur investissement

Le principal élément qui définit le retour sur investissement d’un référentiel de test est le nombre de fois que l’on exécutera un même référentiel pour vérifier la non régression applicative. Voici des critères qui permettent d’accompagner une décision sur ce retour sur investissement :

 Fréquence de versionning applicatif : le premier critère reste le nombre de versions de l’application sur une année. Le retour sur investissement d’un référentiel de test augmentant avec le nombre de non régressions qui seront effectuées. Mais ce seul critère ne peut définir entièrement ce retour sur investissement.

Impact du versionning applicatif : un des points importants à rapprocher du versionning, est l’impact de ces versions. Si le planning de mise à jour applicative est composé de nombreuses versions mais seulement mineures, ou que le versionning consiste en l’ajout de nouveaux modules n’ayant aucun lien avec les anciens, l’effort de non régression sera moins important et le retour sur investissement du référentiel de même.

Durée de vie applicative : par rapport aux deux critères précédents, celui-ci à une influence directe. Une application mise en production pour un besoin particulier, qui sera peut-être obsolète l’année suivante, aura un très faible intérêt à mettre en place un référentiel de test. A contrario, une application qui est mis en place pour servir le métier sur les dix prochaines années à un retour sur investissement plus intéressant.

 Volatilité ergonomique : comme nous venons de le voir dans le chapitre sur l’intérêt d’un référentiel de test, la bonne description de l’ensemble des actions et résultats attendus est essentielle. La volatilité ergonomique de l’application est donc un critère essentiel du retour sur investissement d’un référentiel de test.

Si par exemple un écran est composé de plusieurs onglets permettant de saisir toutes les informations et qu’on décide de diviser cet écran en plusieurs qui s’enchaineront, il faudra alors modifier les actions et les résultats attendus de plusieurs procédures de test pour correspondre aux nouvelles cinématiques écran.

De la même manière si on choisit d’intervertir deux écrans dans une cinématique, il faudra adapter les procédures de test en conséquence.

Donc un système logiciel qui changera souvent d’ergonomie devra de même adapter son référentiel de test, entrainant des investissements supplémentaires. Ce qui aura pour conséquence de faire baisser l’intérêt économique du référentiel, de même que pour l’automatisation des tests.

Volatilité fonctionnelle : de la même manière que précédemment, un logiciel qui à chaque version voit les règles de gestion de toutes ses fonctionnalités modifiées, aura un retour sur investissement du référentiel de test amoindri. Effectivement, à chaque version il faudra modifier l’ensemble des procédures de test, et il ne s’agira plus de faire des tests de non régression, mais à chaque fois de valider des évolutions.

 Complexité applicative : en l’absence de référentiel de test, une équipe de test rencontrera plus de difficulté pour tester un logiciel complexe qu’un logiciel simple. Il faudra à chaque version se rappeler des actions à effectuer afin de tester la non régression applicative. Il est plus aisé de se souvenir du mode de fonctionnement d’un logiciel de gestion seulement basé sur un workflow sans aucune autre règle de gestion, qu’un logiciel enchaînant de nombreuses règles de gestion imbriquées. Il y a donc un réel intérêt à mettre en place des référentiels de test pour tester la non régression des logiciels complexes.

 Instabilité logicielle : ce critère influencera directement l’effort de non régression que l’on souhaitera effectuer à chaque livraison applicative. Plus un logiciel sera instable, plus il sera nécessaire d’effectuer un effort de non régression conséquent pour le stabiliser. On exécutera donc plus souvent le référentiel de test qui aura alors un retour sur investissement plus important.

Coût d’une anomalie en production : chaque logiciel en fonction de son utilisation aura un coût différent des anomalies en production.

Un logiciel Web en front office aura pour chaque anomalie, le coût de correction, ainsi que le coût en termes d’image et de perte de clientèle potentielle. Un logiciel qui gère la ligne de production dans une usine pourra provoquer un arrêt de celle-ci et engendrera des coûts qu’il faudra ajouter à celui de la correction des anomalies.

La plupart des logiciels en fonction de leur utilisation, ont donc des coûts supplémentaires à la seule correction des anomalies détectés en production. Il n’est pas forcément opportun de faire de gros efforts de non régression pour des applications à faible enjeux. Le retour sur investissement du référentiel de test suivra aussi ce chemin.

 Stabilité de l’équipe : une équipe avec un turn-over élevé aura plus de difficulté à gérer les compétences si elle ne possède pas un capital permettant de les transmettre de manière efficace. Un référentiel de test tel que présenté précédemment peut faire office d’un tel relai. Par contre, une équipe stable qui a le temps d’affiner ses compétences fonctionnelles, peut se permettre avec le temps d’exécuter le cahier de test sans l’aide du support d’un référentiel de test structuré.

Maturité de l’équipe en terme de test : comme vu dans le chapitre précédent, l’intérêt d’un référentiel de test est atteint que s’il est réutilisable facilement. Ce degré de réutilisabilité ne peut être atteint que par des personnes aguerries au métier du test. Un référentiel construit par une équipe non mature dans ce métier sera plus difficilement réutilisable, ce qui entraînera une baisse de son retour sur investissement.

Tableau 1: résumé des critères de retour sur investissement d’un référentiel de test

Règles de retour sur investissement

Chaque critère n’est pas suffisant pour tirer une conclusion. Par exemple, une complexité applicative forte va dans le sens d’un retour sur investissement, mais si l’équipe n’est pas mature en terme de test, elle rencontrera d’autant plus de difficulté à construire le référentiel que l’application est complexe. Il sera donc difficilement réutilisable.

De la même manière un logiciel instable qui a une durée de vie courte n’aura pas un retour sur investissement évident du référentiel de test. Il faudra alors regarder l’ensemble des critères pour tirer une conclusion.

Il n’y a pas de règle universelle, chaque cas est unique, mais il existe de grandes orientations. Un logiciel classique en mode versionning, si le référentiel de test est mis en place par une équipe ayant une bonne connaissance des tests, aura un bon retour sur investissement du référentiel. A l’inverse, les logiciels ayant un nombre très faible de fonctionnalité, ont en général une roadmap peu fournie et une assez bonne stabilité qui plaide pour un très faible retour sur investissement.

La politique de test devra définir pour l’organisation les grandes orientations de la mise en place d’un référentiel de test.

Les deux solutions de conception des tests

Comme nous venons de le voir, il n’est pas toujours intéressant de créer un référentiel de test, par contre si on en met un en place, un certain nombre de règles doivent être suivis pour qu’il soit pleinement efficace.

Ces règles imposent une professionnalisation du métier de testeur :

• à la fois pour construire le référentiel de test et le rendre réutilisable, maintenable et automatisable ;
• à la fois pour dégager suffisamment de temps en amont de l’exécution pour le créer, ce qui est difficilement compatible avec le planning des équipes de conception fonctionnelle.

Effectivement, dans le chemin critique projet, les équipes de conception fonctionnelle ne peuvent travailler sur la spécification du référentiel de test que durant la phase de développement logiciel. Or, durant cette phase, elles doivent aussi répondre aux questions potentielles de l’équipe de développement, préparer la mise en production, former les utilisateurs, …, sans parler des retards potentiels qui ont pu être pris sur les tâches précédentes du cycle projet. Ceci est difficilement compatible avec les charges de spécifications d’un référentiel de test de qualité, tel que décrit précédemment.

Solution avec référentiel de test

Si le retour sur investissement est atteint suivant les critères définis précédemment, la solution de spécification des tests consiste donc à mettre en place un référentiel de test. Cela signifie toutes les procédures de test finement décrites, qui permettent de tester l’application sans autre document ou connaissance que celle contenu dans le référentiel. Pour ce faire, une professionnalisation du métier de testeur est obligatoire, comme démontré ci-dessus.

• Avantages : Cf. chapitre éléments de plus-value d’un référentiel de test (qualité des tests, gain de délai projet, indépendance vis-à-vis de la disponibilité d’une ressource, capitalisation …).

La plupart de ces gains sont difficiles à quantifier et dépendent des différentes organisations, mais ils sont néanmoins importants. Par contre le gain en termes de réécriture du référentiel de test de non régression représente entre 5 et 15% du budget de test et ceux pour chacun des projets.

• Inconvénients : Professionnalisation impliquant une séparation des métiers de conception fonctionnelle et de conception de test et donc un projet de transformation et un plan de gestion du changement adéquat. Cette professionnalisation ne peut avoir lieu que s’il y a une masse critique de charge de test dans l’organisation.

Solution sans référentiel et équipe de test

L’autre solution consiste à ne pas mettre en place de référentiel de test et à gérer la couverture de test au travers des exigences de test. Ce cas peut se présenter :

• pour une équipe professionnalisée de conception de test dans le cas où une application ne permettrait par un retour sur investissement d’un référentiel de test ;
• dans le cas de tests effectués par une équipe de conception fonctionnelle.

Même si cette solution est possible avec les deux organisations précédemment citées, les avantages et inconvénients seront établis par rapport à une équipe de conception fonctionnelle. Effectivement, ce cas représente « l’inverse » de la solution avec référentiel de test, et se retrouve souvent dans les entreprises.

• Avantages :
  • Gain de coût induit par la non spécification du référentiel de test (pour rappel environ 9% du coût d’un projet) ;
  • Gain de coût par la continuité des acteurs entre conception fonctionnelle et de test. Mais cet avantage est contrebalancé par l’inconvénient ci-dessous.
• Inconvénients :
  • Non indépendance entre la conception des tests et la conception fonctionnelle, ne permettant pas d’amener un regard extérieur sur celle-ci, ainsi que tous les gains qui y sont liés (les études montrent que 60% à 70% des anomalies projet sont engendrées par des problématiques ou des incompréhensions de niveau conception fonctionnelle (imprécisions, ambigüités, incohérences…)).
  • Même si la méthode sans référentiel de test est une méthode allégée, et que les deux métiers de conception (fonctionnelle et de test) ont des similarités, elle nécessite une connaissance de techniques de test que ne possède pas forcément les équipes de conception fonctionnelle (partitions d’équivalence, valeurs limites, conception par table de décision, règles d’optimisation coût/qualité, cause d’instabilité logicielle…). La qualité de la couverture de test au travers des exigences de test s’en ressentira.
  • Cette méthode représente une charge limitée par rapport à la conception d’un référentiel de test structuré, mais elle intervient lors d’une phase de forte activité pour les équipes de conception fonctionnelle. Il existe donc un risque que les équipes ne puissent pas disposer du temps nécessaire à l’exécution de ces tâches.

Solution intermédiaire

Il existe une troisième solution, mais celle-ci nécessite un niveau d’expertise supérieure aux autres, et une modification plus profonde de l’organisation projet. Elle consiste à traiter les évolutions sous forme d’exigences de test et de sélectionner en fin de projet les tests qui seront écrit finement pour les futures non régression.

Effectivement les équipes de tests étant dans le projet, et hors autres risques, elles ont souvent une connaissance suffisante de l’application pour ne pas avoir besoin de procédures de test fines. Par contre les futures équipes qui feront les non régressions, n’auront pas participées à ce projet, et auront besoin de procédures de test pour les exécuter.

Ceci oblige néanmoins à réfléchir aux futurs besoins de non régression en avance de phase, ce qui peut constituer un exercice assez ardu à réaliser, mais très lucratif en termes de coût de conception des tests. On considère que seulement 10% à 20% des tests des évolutions seront rejoués en termes de non régression futures. C’est donc plus de 80% des tests que l’on écrit pour être joué une seule fois (hors anomalies) par des équipes sachantes… Il s’agit d’une perte sèche au niveau des tests, sans parler de la lassitude au niveau des équipes de test.

Cette solution est pour moi celle qui devrait être mise en place en priorité, mais elle nécessite une réelle expertise au niveau des processus mis en place, que ne possèdent pas forcément actuellement toutes les équipes de test professionnelles.

En synthèse

Le test est un projet à part entière avec un certain nombre de complexités qui nécessite une réflexion préalable au travers d’une politique ou d’une stratégie de test, permettant de répondre au mieux à l’ensemble des problématiques évoquées.

Il n’y a pas de solution unique de spécification des tests, mais une boite à outils du testeur, qu’il doit mettre en œuvre en fonction de l’applicatif et du projet sur lequel il travaille.

Le référentiel de test est une gestion de la connaissance, il faut donc se poser la question d’où gérer la connaissance fonctionnelle permettant de jouer les tests. Elle peut soit se baser sur des ressources humaines et une gestion des compétences dédiée, soit se baser sur la mise en place d’un capital de test au travers d’un référentiel de test, avec toutes les complexités liées à ces deux modes de fonctionnements.

Il faut trouver la bonne organisation des tests en fonction de l’organisation de l’entreprise et des objectifs du métier.

Aujourd’hui, dans la plupart des organisations, les projets portent le coût d’investissement de la mise en place d’un référentiel de test, alors qu’il s’agit principalement d’un investissement pour mettre en place la non régression des futures versions applicatives. Il en ressort que c’est souvent un des premiers postes à être sacrifié, étant donné qu’il est non obligatoire à la version, comme présentée plus haut. Si on veut investir plus facilement dans un référentiel de test de qualité et en récolter les fruits, le budget et l’organisation de celui-ci ne doit pas être porté par le projet mais par les gestionnaires applicatifs ou la structure porteuse.

Pour finir, les techniques permettant de gérer un référentiel de test fin, son organisation et sa maintenabilité tel que décrit ici, ou une gestion de la traçabilité et du reporting au travers d’exigences de test, serait trop long à aborder ici et nécessite un article à part.

À propos de l’auteur: Arnaud Verin

Officiant depuis maintenant 20 ans dans la qualité logicielle, Arnaud est intervenu sur quasiment tous les rôles. De testeur fonctionnel, technique et automaticien, en passant par responsable d’équipe et chef de projet, il tient aujourd’hui un double rôle :
• D’un côté directeur de projet, il met en place des stratégies de test pour de gros programmes, des centres d’excellence test ;
• De l’autre réalisant des missions de conseil, audit, diagnostic, mentoring et formation pour accompagner les entreprises à optimiser leur processus de test manuel et automatique.