Qu’est ce qu’une stratégie de test ?

Si vous travailler dans le test et la qualité… Ou même si vous travaillez à la construction de services numérique vous avez sûrement déjà entendu parler de stratégie de test.
Pour rappel, une stratégie de test est, d’après l’ISTQB: Une description de la manière de réaliser les tests pour atteindre les objectifs de test dans des conditions données. Cette définition a évolué depuis 2019 et l’écriture de cet article.
Dans les faits, c’est un document (niveau entreprise d’après les certifications ISTQB et niveau projet / produit dans la majorité des organisations) qui décrit (liste non exhaustive, chaque élément n’est pas forcément présent non plus) :
- les rôles et responsabilités
- les types de tests effectués
- l’organisation et le processus de test
- l’organisation des campagnes de test
- la gestion des bugs
- la gestion des données et environnements
- l’automatisation des tests
- les outils disponibles
- les processus et méthodologies utilisées
- les critères d’entrée et de sorties…
Sur le papier c’est assez clair et semble vraiment centré sur les « tests » ce qui explique le nom… Néanmoins ce n’est pas si simple!
Le souci avec le nom « stratégie de test »
Depuis mes débuts professionnels j’ai souvent été amené à concevoir ou mettre à jour des stratégies de test.
Que cela soit en cycle en V ou en Agile (même si c’est beaucoup plus flagrant en Agile) une stratégie de test n’est pas un document pour le testeur!
De même, une stratégie de test, n’est pas exclusivement liée au activités de test au sens où on l’entend.
Ce qui est bien c’est que je n’ai encore jamais été amené à faire de la pédagogie sur ce sujet dans les différentes organisations où je suis intervenu. Les acteurs avec lesquels j’échange voient bien la stratégie de test comme un document global qui concerne tous les acteurs… Pour tout vous dire il m’est même arrivé que des clients me précisent que la stratégie de test impliquent aussi les développeurs et le métier!
Le nom stratégie de test peut donc être trompeur… Notamment pour des profils junior.
Une stratégie de test aborde des phases du cycle de développement bien plus larges que les phases de test. Je pense notamment à:
- la phase de définition du besoin. Exemple: le BDD est là pour challenger le besoin et la valeur
- la phase de conception. Exemple: le BDD, encore lui, permet de challengerles solutions à un besoin
- la phase de développement. Exemple: le notions de couverture de code des tests unitaires, la nécessité des revues de code…
- la phase de préparation des tests. Ex: techniques de conception des tests, gestion des environnements et données, revues de tests…
- la phase de test: quelles campagnes à quel moment
- des phases transverses. Exemple: l’automatisation et la CI/CD
- la phase de validation. Exemple: validation par des utilisateurs en UAT, organisation de campagne de test exploratoires avec le métier.
- la phase de déploiement. Exemple: utilisation du canary release…
Comme vous pouvez le constater, l’ensemble des acteurs est concerné par la stratégie de test. Cela semble évident quand on adopte le point de vue que les deux principaux but des test sont de
- déterminer si la qualité d’un service est suffisante pour que ce service soit remis entre les mains de ses utilisateurs
- atteindre cette qualité au coût le plus bas possible.
L’apport principal d’une stratégie de test
Le but principal d’une stratégie de test est pour moi assez similaire à celui du BDD: aligner les différents acteurs qui contribuent à proposer un service numérique. Là où le BDD se concentre sur les fonctionnalités à développer dans une équipe, la stratégie propose une vision plus large.
Plus large en termes de personnes concernées: tous les contributeurs à la construction du service
Plus large en termes d’activités: on va au delà de ce que l’on va développer prochainement.
Une stratégie de test réussie
Une stratégie de test efficace (et réussie) n’est donc pas une stratégie qui couvre tous les aspects que j’ai abordé en première partie!
Une stratégie de test réussie est pour moi une stratégie de test qui rassemble. Une stratégie que tout le monde s’approprie, une stratégie qui a pour objectif la qualité… Une stratégie qui évolue avec le contexte.
Il n’y a, pour moi, aucun problème à commencer « petit » avec une MVS (Minimum Valuable Stratégie :D) puis la faire évoluer au fur et à mesure. A l’image d’un service numérique, une stratégie doit s’adapter aux changements.
Conclusion
Une stratégie de « test » ne se limite pas au « test ». Une stratégie de test parle de « qualité » et à ce titre elle embarque toutes les personnes qui contribuent à construire et faire évoluer le service numérique.
De même, une « stratégie » de test n’est pas uniquement une stratégie. Elle doit aussi être une vision partagée, un document qui rassemble et qui vit.
Au final, le nom de stratégie de test mais il est très compliqué de donner un autre nom qui permettrait de rassembler tous les rôles d’une bonne stratégie de test.
Vulgarisateur et facilitateur du test et de la qualité chez K-LAGAN – Animateur de « La taverne du testeur »