Glossaire · Fondamentaux du test
Test basé sur les risques
En anglais : Risk-based testing
Également appelé : test fondé sur les risques, tests basés sur les risques, stratégie de test basée sur les risques
Définition
Approche qui priorise l'effort de test selon le risque (probabilité de défaillance x impact) pour tester d'abord et plus en profondeur les zones les plus risquées.
Le test basé sur les risques (risk-based testing) part du principe qu’on ne peut jamais tout tester et décide où investir son temps en fonction du risque. Chaque fonctionnalité ou zone reçoit une note de probabilité de défaillance (complexité, volume de changements, défauts passés, technologie nouvelle) et d’impact en cas de défaillance (argent, sécurité des personnes, données, exposition juridique, nombre d’utilisateurs). Les zones à risque élevé sont testées plus tôt, plus en profondeur et de façon plus variée ; les zones à faible risque reçoivent des vérifications plus légères.
Exemple
Une release touche quatre zones. Notez chacune de 1 à 5 :
| Zone | Probabilité | Impact | Risque (P x I) | Profondeur de test |
|---|---|---|---|---|
| Migration du prestataire de paiement | 5 | 5 | 25 | Fonctionnel complet, cas négatifs, intégration, performance, exploratoire |
| Nouvelles règles de taxe pour une région | 4 | 4 | 16 | Tests aux limites et par table de décision, régression des totaux |
| Page de profil repensée | 3 | 2 | 6 | Parcours principaux et contrôle visuel |
| Mise à jour d’un lien du pied de page | 1 | 1 | 1 | Vérification rapide |
Si l’échéance est raccourcie de deux jours, vous savez déjà quoi abandonner : la profondeur sur les lignes à faible risque, pas la migration du paiement.
Pourquoi c’est important
Tout plan de test fait des compromis. Le test basé sur les risques les rend explicites et partagés. Il donne aussi un moyen clair de rendre compte de l’avancement : « toutes les zones à risque élevé sont testées, deux risques moyens le sont partiellement, et ces lacunes connues demeurent » est bien plus utile pour une décision de mise en production que « 83 % des cas de test exécutés ».
Erreurs fréquentes
- Noter seul. Les product owners connaissent l’impact, les développeurs la probabilité. Évaluez les risques ensemble.
- Noter une seule fois. Les risques évoluent à mesure que le code arrive et que des bugs apparaissent. Un module qui ne cesse de produire des défauts doit monter dans le classement.
- Ignorer complètement les zones à faible risque. Risque plus faible signifie tests plus légers, pas absence de tests. La régression automatisée couvre généralement cette base.
- Confondre risque et sévérité d’un bug. La sévérité qualifie un défaut déjà trouvé. Le risque est une estimation faite avant les tests, qui sert à décider où chercher.