Le marché actuel très changeant impose aux organisations des changements rapides et fréquents.
Pourtant, il est impératif de garantir le respect de multiples contraintes liées à la stabilité et à la déployabilité des solutions, tout en conservant leur intégrité et leur valeur intrinsèque.
La stratégie de test est un des artefacts importants qui permet de répondre à la question : “Suis-je capable de garantir à mes utilisateurs le service rendu, et ceci dans le temps malgré tous les aléas prévisibles ou non ?”
C’est un document dont le but est souvent mal compris, pas toujours très bien utilisé, mais qui va permettre de guider les équipes projet dans la construction du produit et des tests associés.
Dans cet article, nous allons voir l’importance d’une stratégie de test, son contenu et ses acteurs, comment la construire, et comment évaluer sa pertinence pour l’améliorer en permanence.
Pourquoi une stratégie de test ?
Un projet, que ce soit dans le monde matériel ou logiciel, comporte des risques plus ou moins importants et faciles à identifier.
Ces risques sont liés au fait de produire une valeur que l’on voudra éviter de perdre du fait de “régressions” et d'un mauvais fonctionnement lors des différentes évolutions.
La stratégie de test répond à ce besoin en fournissant un cadre de qualité au développement et au test.
Lors du développement d’un logiciel, plus que dans tout autre domaine, les régressions, ou bugs, ou effets indésirables sont un impondérable lors de l’ajout de fonctionnalités ou de cas d’utilisation.
Pour garantir d'une part que la valeur à livrer a été correctement produite et qu'elle sera maintenue sur la durée, nous nécessitons une méthodologie claire.
Cette dernière permettra aux équipes de s'appuyer dessus pour élaborer les plans de tests et concevoir des tests qui minimisent les risques identifiés, tout en adaptant le produit au rythme dicté par le marché ou l'organisation.
Les jeunes entreprises commencent souvent en testant “au fil de l’eau”, afin de vérifier que ce qui est livré correspond bien au besoin.
Elles accumulent un patrimoine de tests qui devient au fil du temps difficile à gérer et à évaluer, coûteux en temps d’exécution et dont la pertinence diminue avec l’évolution du produit et du contexte marché.
D'où l'importance de formations et certifications, comme la certification ISTQB, pour mieux gérer et optimiser ces tests.
Cela souligne également l'importance d'évaluer régulièrement la maturité des tests logiciels pour s'assurer que les pratiques de test évoluent de manière appropriée avec l'entreprise.
Il devient donc nécessaire pour l’organisation de prendre de la hauteur et de construire deux artefacts “au-dessus” de ce patrimoine de tests :
La politique de tests a pour rôle de répondre à la question du “pourquoi teste-t-on ?” et “dans quel but, pour aller dans quelle direction ?”
Une fois la politique de test établie, la stratégie de test va permettre de cadrer le “comment atteindre les objectifs fixés par la politique de tests ?”, et va donc expliciter le cheminement et les moyens mis en œuvre pour que les tests soient les plus efficients possibles.
Une définition de la stratégie de test
L’ISTQB définit la stratégie de test de la manière suivante :
"La stratégie de test est le document de haut niveau définissant, pour un programme, les niveaux de tests à exécuter et les tests dans chacun de ces niveaux (pour un ou plusieurs projets)".
Il s’agit donc d’un document fixant les tests répartis par niveau dans la pyramide des tests, le RACI pour chacun des niveaux et les attendus en termes d’objectifs pour chacun des types de tests mis en œuvre.
C’est à partir de ce document que les équipes de développement du produit vont construire les plans de tests, ou simplement implémenter les tests internes au produit (tests unitaires et d’intégration par exemple). Et ce, afin que le produit réponde durablement aux exigences du marché et puisse s’y adapter en permanence.
Pour mettre en place une stratégie de test efficace, il est également important d'utiliser les outils et les techniques les plus adaptés, comme l'automatisation des tests.
Quelles en sont les limites ?
Étant un document émis au niveau de l'entreprise au même titre que la politique de tests, la stratégie de test ne doit pas prendre en charge des spécificités liées à certaines équipes, organisations ou opérations, au risque de sur-contraindre le développement du produit et de le rendre inapte à suivre les évolutions rapides du marché ou des technologies.
La prise en charge des spécificités est donc le rôle des plans de tests.
- La stratégie de test doit rester au haut niveau et générique. Il s’agit d’un compromis, d’un cadre pour les équipes et projets
- L’adaptation de la stratégie, donc la tactique, est le rôle des plans de tests, pris en charge dans les équipes et projets
- La stratégie de test ne spécifie pas le pourquoi, c’est le rôle de la politique de tests, rédigée au niveau "organisation"
- La complexité de la stratégie de test doit être adaptée à l’organisation cible. Elle sera beaucoup plus simple sur de petits projets très Agiles que pour de grands projets critiques (défense, aéronautique, finance, …)
- La stratégie de test ne couvre “que” les tests, elle ne dédouane pas d’une bonne conception propre et de bonnes pratiques de travail et de codage (clean code, clean architecture par exemple)
Comment construire une stratégie de test ?
Si nous revenons à la définition de la stratégie de test, un des éléments fondamentaux est de partir des objectifs définis dans la politique de tests, et notamment “où voulons-nous aller ?”
La plupart du temps, l’organisation, l’équipe, l’entreprise développant le produit, a une idée un peu vague de ce qui est attendu, mais les critères qualitatifs sont souvent liés à la fiabilité du produit, à la disponibilité des fonctionnalités livrées dans le temps, à l’absence de “bugs” gênants pour le client, à la performance, à la sécurité, et à d’autres critères bien définis.
Les étapes à suivre pour construire efficacement une stratégie de test sont les suivantes :
1) Identifier les modes de défaillances
La première étape lors de la construction d’une stratégie de test va donc être de traduire les objectifs fixés par la politique de tests en critères précis, et de poser la question pour chacun d’eux “quels sont les facteurs internes ou externes pouvant invalider ce critère ?”. Ce que l’on appellera en analyse de risque : les modes de défaillance.
Une fois ces modes de défaillance définis, et parfois classifiés, les tests vont pouvoir répondre à deux questions :
- Comment garantir que je livre bien la valeur et uniquement la valeur attendue par le marché ?
- Et comment garantir qu’un mode de défaillance, s’il intervient, ne remette pas en question la valeur présente dans mon produit ou mon service ?
Nous avons alors à ce stade des facteurs de risques.
2) Mettre en place une stratégie de défense par les tests
L’étape suivante consiste à répondre à la question : comment prévenir ou éliminer ce risque ?
La méthode AMDEC, et l’ISTQB, nous indique qu’un risque peut être caractérisé par sa criticité C, soit par le produit de sa probabilité d’occurrence P, de sa gravité G ou de sa non-détectabilité D.
Cela nous donne la formule suivante :
Criticité = Probabilité * Gravité * Non-Détectabilité
Réduire le risque, c’est donc réduire un ou plusieurs des facteurs.
Modèle AMDEC
L'illustration suivante présente un exemple d’AMDEC appliqué à des composants logiciel et matériel :
Évaluation des modes de défaillances et répartition des tests avec le modèle AMDEC
La stratégie de test va donc expliquer comment procéder en utilisant les tests.
On va chercher à indiquer leur niveau (en essayant de respecter le principe de la pyramide de tests), les conditions d’exécution, les données et paramétrages à mettre en œuvre, et le responsable du test ou du niveau de test à mettre en œuvre.
On indiquera également si possible à quel moment et sous quelle forme le test est joué, et comment seront traités les résultats des tests.
La stratégie de test mettra aussi en avant l’audit des tests : c'est-à-dire à quelle fréquence et par qui les tests seront revus et mis à jour pour éviter qu’ils ne deviennent trop nombreux, obsolètes, et en conséquence que la stratégie de test ne perde de sa pertinence et de sa valeur pour l’organisation.
Mais quel niveau choisir en priorité ? Comment savoir quels tests effectuer à quel moment et comment être sûr que les tests sont bien répartis ?
Deux principes peuvent aider à répondre à cette question :
2.1 Le quality by design
C'est un principe qui veut que le produit embarque tout ce qui est nécessaire à la garantie d’une qualité totale du point de vue de l’utilisateur.
On cherchera donc à embarquer les tests au plus près du code et à conserver le code le plus testable possible.
Pour les produits non logiciels, le matériel pourra embarquer soit des autotests embarqués, soit des poka-yoké afin de rendre impossible une construction du produit en l’absence de défaut ou de mauvaise manipulation.
2.2 Le shift-left
Aussi appelé décalage à gauche, il signifie que plus un défaut est détecté plus tôt, plus sa correction est facile à effectuer, et plus le coût de correction deviendra faible.
En utilisant ces deux principes, il est possible de fixer des règles de sélection des tests en fonction de leur proximité avec le système et leur capacité à être mis en place tôt dans le processus de développement.
Dans le cas d’un logiciel, nous aurons par exemple dans l’ordre : les analyses statiques de code, les tests unitaires, les tests d’intégration, les tests d’API, les tests de bout en bout et enfin les tests exploratoires. Cette classification nous permet de retomber sur la “pyramide des tests”.
L'image suivante présente un exemple de pyramide de tests
3) Attribuer des pilotes aux différents niveaux de test via le RACI
Un des éléments importants dans la qualité d’un projet est la connaissance de la responsabilité de chaque acteur dans les étapes des différents processus conduisant à l’ajout de valeur au produit.
La stratégie de test porte réellement cette répartition des responsabilités.
Elle identifie pour chaque niveau de tests les éléments suivants :
- Le type de test
- Les limites de ce que ce niveau teste
- Qui implémente les tests du niveau et quand
- Le non testé et les risques associés (et assumés)
Ce point est souvent un grand oublié des stratégies de test. Il est pourtant essentiel et sera demandé lors d’un audit ISO 9001 au titre de la maîtrise des risques, notamment si une partie du produit est fournie par un prestataire et doit faire l’objet de contrôles qualité.
Podcast : Utiliser l'IA pour améliorer les tests logiciels
Ecoutez ce podcast pour découvrir comment intégrer l'intelligence artificielle pour améliorer les tests logiciels :
Une stratégie de test, quand et rédigée par qui ?
La stratégie de test s'élabore après la détermination du contenu cible. Elle doit être rédigée et validée en temps opportun par des acteurs clés tels que les testeurs, les analystes métier (BA) et d'autres participants essentiels du développement.
Ces deux questions peuvent paraître simples, mais dans la mesure où une stratégie de test est un document structurant, voire un accord et un engagement de la part des différents acteurs du développement d’un produit ou service, il y a certains enjeux.
En effet, le fait d'oublier une personne dans la rédaction ou de construire la stratégie trop tôt ou trop tard, peut conduire soit à un coût élevé des tests, soit à une inadéquation des plans de test aux risques projets et donc à des coûts de rattrapage de la qualité.
La stratégie de test est un document collaboratif entre les différentes équipes et acteurs d’un développement. Elle regroupe les informations sur ce qui sera testé ou non, met en valeur la limite de risque communément acceptée.
De ce fait, c'est un document construit durant les phases de conception du produit dans sa globalité, de préférence de manière itérative pour faciliter l’émergence d’un compromis et une bonne correspondance avec l’évolution de la connaissance produit.
Toutefois, si le projet utilise des cycles en V, il est possible de ne la mettre à jour que de manière ponctuelle au début de chaque cycle.
Chaque contributeur doit donc durant ces phases de découverte se poser différentes questions :
- Quels sont les niveaux de test qui m’incombent ?
- Quels sont les risques détectables via ces niveaux de tests ?
- Est-il nécessaire de faire évoluer la conception pour réduire les facteurs de risque (probabilité, gravité, non-détectabilité) en adaptant la conception pour la rendre plus testable ?
- Quel est le but visé par mes tests ? (Détecter un défaut au plus tôt, valider la bonne implémentation d’un parcours client, détecter une dérive d’une variable de suivi, guider la conception, …)
- Quels sont les autres acteurs en interface avec les tests dont j’ai la responsabilité ? Quelles sont les informations à échanger avec eux pour faciliter le codéveloppement de la stratégie et plus tard des tests ?
Cette stratégie sera d’autant plus importante et complexe que le produit est complexe. Elle est donc un bon indicateur d’une solution trop complexe que l’on va devoir simplifier pour pouvoir la livrer en maîtrisant les coûts et les délais.
Mais renoncer à la stratégie de test, c’est aussi rendre invisible des coûts et délais qui constitueront une “dette” technique et organisationnelle pouvant mettre en péril le projet lors des phases de livraison, de réception et de maintenance.
Modèle de la stratégie de test
Comme expliqué plus haut, une stratégie de test est matérialisé par un document de référence, dont la trame :
- Les objectifs et le contexte du document
- Le contexte général et la méthodologie utilisée pour construire la stratégie de tests
- La définition des tests effectués et leur but
- L'analyse des risques avec le modèle AMDEC
- La répartition des tests par niveau
- La déclinaison du document en plans de tests
- Les approbations
Ci-après un exemple de trame sur un exemple de test informatique :
Télécharger ce modèle de stratégie de test
Les erreurs à éviter lors de la construction de la stratégie de test
Dans l’élaboration de votre stratégie de test, prenez garde de ne pas commettre les erreurs suivantes :
1) Confier sa conception à un seul acteur
Comme lors de tout processus de coconstruction, une des erreurs les plus fréquentes est de confier la construction de cette stratégie de test, une fois le développement lancé, à un seul et même acteur, souvent un testeur, un chef de projet ou un responsable produit.
La stratégie de test ne sera donc pas un outil, mais un document regroupant de l’information figée.
Elle pourra de ce fait devenir inapplicable à un produit difficilement testable, et lister des risques dont la gravité, la probabilité ou le risque de non-détectabilité seront mal évalués, ce qui conduira à des tests mal répartis, et à des coûts de maintenance élevés en fin de projet.
2) Considérer la stratégie de test comme un document figé
Une autre erreur est de considérer la stratégie de test comme un document figé, rédigé en une seule itération et non réévalué.
En effet, dans la mesure où il s’agit d’un document qualité, il doit faire l’objet d’audits réguliers, et servir de document de support pour garder une bonne maîtrise et une bonne connaissance des risques par l’ensemble des acteurs du projet.
Conclusion
Une stratégie de test est un document qui va guider la construction du produit et ses tests associés, grâce auquel les risques peuvent être identifiés et traités rapidement.
En suivant les étapes de cette stratégie de test et en évitant les erreurs communes de la méthodologie, vous pourrez avoir des résultats fiables et atténuer la criticité des risques.
