Il m’est arrivé assez souvent de mettre en place, pour des programmes, des stratégies de test avec 40 à 50 phases de test, forcément il faut cadrer les objectifs de chacune pour que le projet de test se passe bien. D’où l’intérêt d’une stratégie de test.
La stratégie de test
La stratégie de test est un document de cadrage projet, qui est là pour organiser l’ensemble des niveaux et types de test (test fonctionnel, technique…). L’objectif de la stratégie est de définir les phases de test permettant de valider les besoins de qualité du projet, leurs dimensionnements, ainsi que les acteurs en charge de celles-ci.
Ce document sera suivi d’un plan de test pour chacune des phases de test. Ces plans définiront de manière détaillé l’ensemble des moyens humains et techniques nécessaires à la réalisation de la phase de test en question.
Ces plans seront eux-mêmes suivis, en fonction des besoins, de cahiers de test référençant de manière détaillée les scénarios et cas de test à exécuter.
Généralement il y a une confusion entre stratégie de test et plan de test. Ceci vient notamment du fait qu’en RUN la stratégie est faite une fois pour toute et appliquée pour une version sous la forme d’un plan de test. Ce qui apporte de la confusion pour les équipes.
Pourquoi une stratégie de test
Les tests sont une des seules tâches du projet pour laquelle tout le monde participe activement.
- La MOE
- L’AMOE
- L’AMOA
- Le métier
- La production
- …
Il est donc aisé pour des problèmes de communication d’avoir des trous dans le périmètre de test ou un dédoublement des tests. Chacun voulant garantir la qualité du système à lui tout seul, mais néanmoins en présumant de ce que l’autre fera.
Au-delà de ces points, chaque acteur a des forces et faiblesses qu’il convient d’aborder de manière conjointe, dans un objectif de qualité globale.
On entend dire qu’il n’y a pas besoin de stratégie de test pour de l’agilité. Mais le sujet ne se situe pas à ce niveau. Si on est sur du mono applicatif on peut effectivement poser une stratégie sur un bout de table, mais finalement qu’on soit en agilité ou autre, la réalité est la même. Par contre si on a un projet/programme avec plusieurs équipes agiles, il faut prévoir le lien entre les squads, les différents niveaux d’intégration, ceci est à rapprocher de l’agilité à l’échelle. Le besoin de stratégie de test est donc impératif.
Méthodologie de construction de la stratégie
Afin d’atteindre l’objectif de définition des phases de test, il convient de définir des briques applicatives, et pour chacune, en fonction de leurs éléments projet et de future production, définir les niveaux et types de test s’y appliquant. Ces niveaux et types de test seront alors eux-mêmes découpés ou regroupés en phase de test, en fonction des besoins calendaires et de compétences humaines.
Les briques applicatives représentent des applications du SI ou des applications connexes.
Les niveaux de test correspondent aux différents degrés d’intégration dans le SI, et seront définis par la suite.
Les types de test sont les différents aspects qui peuvent être vérifiés (fonctionnel, ergonomie, portabilité, sécurité, performance…), et seront définis par la suite.
Les Briques applicatives
Souvent les projets informatiques ont une vue trop technique qui engendrent des « applications » qui n’en sont pas. Pour des besoins d’architecture, on peut par exemple créer des middlewares qui sont des conglomérats de fonctionnalités techniques.
Une brique applicative est un ensemble fonctionnel cohérent, permettant d’apporter un service pour le métier.
Les niveaux de test
Il est parfois compliqué de diagnostiquer une anomalie. Pour s’en prémunir, il convient de mettre en place des niveaux de test qui vont monter en complexité d’intégration applicative.
Outre cet aspect, cette stratégie d’intégration progressive, permet aussi de gérer les cas d’utilisation en fonction de leurs impacts fonctionnels ou de niveau processus, et ainsi de gérer de manière plus aisé la couverture de test, en la répartissant entre les différents niveaux.
Un expert d’un métier coûte souvent plus cher qu’un développeur et les environnements bout en bout de même. Il faut donc faire le plus de test de bas niveau. Sachant qu’on aura néanmoins besoin d’un expert pour certains cas d’utilisations. Un développeur peut tester sur son poste, alors qu’un expert aura besoin d’un SI entier, qu’il faudra interconnecter, mettre à jour au niveau des données … Le processus de correction et d’échange est plus court et efficace en descendant dans les niveaux de test. Il est plus facile de diagnostiquer une anomalie quand peu de système sont impactés, et que l’on sait que chacun fonctionne unitairement.
La stratégie doit trouver la bonne répartition du périmètre de test entre tous les niveaux et acteurs. Il faut voir le périmètre de test comme un gâteau qui garantit la qualité souhaitée en production, et cet effort est forcément global. La stratégie est là pour découper le gâteau en fonction des niveaux et acteurs pour en assurer la cohérence. Souvent en l’absence de stratégie de test chacun fait son petit gâteau et on essaye tant bien que mal, de faire un gros gâteau sur la base de plusieurs petits. Je vous laisse à vos fourneaux pour y arriver… Mais la démarche doit être l’inverse, et c’est bien l’objectif de la stratégie. On fait un gros gâteau et on le découpe par la suite. De cette manière on est certain du contenu du gros gâteau…
Dans ce cadre là, les niveaux de test suivants sont souvent utilisés :
- Test unitaire
- Test d’intégration
- Test fonctionnel
- Test système
- Test 2 à 2
- Test SI
- Test en production (dans le cas où certains éléments ne pourraient être simulés avant)
Incompréhensions sur les niveaux de test
Tout le monde parle de tests unitaires en parlant de choses différentes. En fait tout dépend du prisme qui définit le mot unitaire.
- Pour un fonctionnel cela sera une règle de gestion.
- Pour un métier cela sera une fonctionnalité.
- Pour un développeur cela sera une fonction de son code.
De la même manière, on retrouve des incompréhensions sur le bout en bout : test de l’entièreté du SI pour un métier, test de l’assemblage de plusieurs bouts de code pour un développeur.
La stratégie est donc surtout là pour définir le vocabulaire utilisé et se mettre d’accord entre les acteurs pour éviter toute incompréhensions ayant un impact sur la couverture de test.
Niveau de test et acteurs
Le niveau de test ne présume pas obligatoirement de l’acteur.
Normalement plus on monte, plus on se rapproche du métier, mais pour des raisons de qualité ou autre, le métier peut par exemple participer aux tests fonctionnels ou système.
Les types de test
Les tests fonctionnels regroupent les tests des fonctionnalités suivant leurs règles de gestion et leur futur paramétrage de production. Un test sans le bon paramétrage n’ayant pas valeur de validation. Une gestion de configuration des sources et du paramétrage des briques applicatives est donc essentielle.
Tests d’ergonomie de type UX, langue, navigabilité, simplicité du processus, les tests d’ergonomie sont souvent des tests non formels.
Les tests de portabilité se focalisent sur la vérification de l’utilisation de la brique applicative sur des environnements de navigateurs ou matériels différents.
Les tests de sécurité portent sur la vérification statique des failles de sécurité, ainsi que sur des tests d’intrusion réalisés par des profils compétents.
Les tests de performance traitent des délais de réponse de l’applicatif à différent taux de sollicitation, ainsi qu’en stress et en robustesse. Ces tests doivent traiter les retours IHM ainsi que les délais batchs.
Les tests d’exploitation concernent tous les aspects traités par les futures équipes d’exploitation. Les types de test concernés sont : installation, plan batch, supervision, métrologie, fiche incident, crash système …
Les tests de sauvegarde / restauration consistent en la vérification du bon déroulé des plans de sauvegarde et de l’utilisabilité applicative suite à restauration des bases de données.
Les phases de test
Les phases de test sont à la rencontre d’un niveau de test (assujetti à une ou plusieurs briques applicatives) avec un type de test et un acteur. On peut par exemple avoir plusieurs phases de test de performance à des niveaux différents. De la même manière les métiers peuvent intervenir au niveau système et SI pour éviter les effets tunnels.
Attention la non régression n’est ni un niveau de test ni un type de test, c’est une autre dimension à l’équation. On peut faire de la non régression sur des tests unitaires, sur de la performance ou autre.
Conclusion
Comme nous venons de le voir, la stratégie de test est un moment de partage indispensable au bon déroulement d’un programme, lié à la multiplicité des acteurs et niveaux d’intégration.
Néanmoins même sur un projet mono applicatif, en agile ou non, il faut se poser la question de quels tests font le métier, les fonctionnels et les équipes techniques, pour éviter les redondances de test et les trous dans la raquette. Et surtout qui fait les tests de régression et suivant quelle profondeur ?
À 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.
2 Responses
Dans les différents rôles associés à chaque niveau de test, le testeur n’est pas mentionné. Ainsi, est-il présent sous une autre appellation ou est-il sous-entendu ?
Il est sous entendu. On parle de testeur MOE, testeur AMOE…