Écrire une stratégie de test qui survit au premier sprint
La plupart des stratégies de test finissent au fond d'un wiki. Voici comment en produire une qui reste utile : centrée sur le risque, courte et révisable.
Une stratégie de test de trente pages validée en comité, personne ne la relit. Une page révisée à chaque incrément, tout le monde s’en sert. La différence n’est pas la rigueur : c’est le format et la fréquence de mise à jour.
Partir du risque, pas de la couverture
L’erreur classique consiste à viser un pourcentage de couverture. Un chiffre rassure, mais il ne dit rien de ce qui casserait vraiment le produit en production. La question utile est : qu’est-ce qui, si ça se produit, nous coûte le plus cher ?
Pour un système de distribution ferroviaire, la réponse tourne autour de trois axes :
- l’impossibilité de finaliser un achat (perte de revenu directe) ;
- une tarification erronée (perte de confiance, litiges) ;
- une régression sur l’après-vente (échange, remboursement, service client saturé).
Tout le reste passe après. La stratégie hiérarchise ces risques et associe à chacun un niveau d’effort de test, pas l’inverse.
Une grille simple
| Risque | Impact | Probabilité | Effort de test |
|---|---|---|---|
| Paiement KO | Élevé | Moyenne | Automatisé + exploratoire à chaque release |
| Tarif erroné | Élevé | Faible | Automatisé sur jeux de données de référence |
| Bug cosmétique | Faible | Élevée | Revue visuelle, pas de test dédié |
Écrire court
Une stratégie exploitable tient sur une page :
- Objectif - ce qu’on cherche à sécuriser ce trimestre.
- Périmètre - ce qui est couvert, et surtout ce qui ne l’est pas.
- Approche par niveau - unitaire, intégration, bout-en-bout, exploratoire.
- Critères de mise en production - la liste qui autorise ou bloque un déploiement.
- Ce qu’on accepte de ne pas tester - explicitement.
Le cinquième point est le plus important. Une stratégie qui ne dit pas ce qu’elle laisse de côté n’est pas une stratégie, c’est une liste de vœux.
La réviser à cadence fixe
Rattachez la revue de la stratégie à un rituel existant : revue de sprint, préparation de release, rétrospective mensuelle. Trois questions suffisent :
- Un risque a-t-il changé de niveau depuis la dernière fois ?
- Un critère de mise en production s’est-il révélé inutile ou manquant ?
- Qu’avons-nous laissé passer en production, et pourquoi ?
Ce que ça change concrètement
Une stratégie courte et vivante déplace la discussion qualité en amont. Les arbitrages « on teste ou pas » se prennent en connaissance de cause, pas dans l’urgence de la veille de release. Et quand un incident survient, on sait si on avait fait le choix de ne pas le couvrir - ou si on a un angle mort à corriger.