Leadership en Test : Test basé sur les risques
Note de la rédaction : Bienvenue dans la série Leadership en test du gourou et consultant en tests logiciels Paul Gerrard. La série est conçue pour aider les testeurs expérimentés – en particulier ceux en équipe agile – à exceller dans leurs rôles de responsables et de gestionnaires de tests.
Dans l’article précédent, nous avons examiné l’importance des modèles de test. Ici, nous allons plonger dans le concept de risque et proposer un manifeste de test basé sur le risque que vous pourrez appliquer à votre propre méthodologie de test orientée risque.
Inscrivez-vous à la newsletter The QA Lead pour être averti lorsque de nouveaux épisodes de la série sont publiés. Ces articles sont des extraits du cours Leadership en test de Paul, que nous recommandons vivement pour approfondir ce sujet et d’autres thématiques. Si cela vous intéresse, utilisez notre code exclusif QALEADOFFER pour bénéficier de 60 $ de réduction sur le prix du cours complet !
Les risques, s’ils se matérialisent, ont un effet néfaste sur nos projets. La gestion des risques consiste à identifier les risques existants et à prendre des mesures pour réduire leur probabilité, les éliminer, ou réduire leur impact sur les objectifs de nos parties prenantes.
Dans certaines entreprises, la gestion des risques s’effectue avec une précision d’ingénierie et mathématique. Dans le domaine logiciel, il n’est pas possible d’être aussi précis. La plupart des organisations ne pratiquent toujours pas une approche systématique du test basé sur le risque. Mais il y a une bonne raison à cela : une fois identifiés, les risques liés aux produits logiciels sont souvent extrêmement difficiles à évaluer.
Du point de vue du test et de l’assurance, un risque représente un « mode d’échec sur lequel il convient de se pencher ». Le test basé sur le risque consiste à modéliser les modes d’échec potentiels du système comme des risques produits afin de faciliter le cadrage, le dimensionnement et la priorisation des tests.
Dans cet article, je propose un manifeste du test basé sur le risque. Nous examinerons la gestion classique des risques et verrons comment l’adapter pour qu’elle soit utile aux testeurs. Enfin, nous aborderons quelques aspects pratiques et considérations pour vous aider à mettre en œuvre votre propre approche de test orientée risque.
- Risques projet, processus et produit
- Un manifeste du test basé sur le risque
- L’approche classique du risque
- Risque produit et test
- Aspects pratiques
- Comprendre le rôle du test dans la gestion des risques
Nous utiliserons cette définition du risque : Un risque est une menace qui pèse sur un ou plusieurs objectifs des parties prenantes d’un projet, avec une probabilité incertaine.
Risques projet, processus et produit
Il existe des centaines de livres sur le risque et la gestion des risques décrivant de nombreuses approches pour gérer le risque au niveau du projet. Typiquement, ces approches se concentrent sur ce que nous nommerons les risques de projet et de processus, en se limitant parfois à un unique risque intitulé par exemple « non-respect des exigences ». Un unique risque sur les exigences n’est pas très utile, car il ne permet pas de prioriser efficacement un risque par rapport au test.
On distingue trois types de risques logiciels.
Risque projet : Ces risques concernent le projet dans son contexte propre. Les projets comportent généralement des dépendances externes telles que la disponibilité des compétences, la dépendance à des fournisseurs, des échéances ou des contraintes fixées, comme un contrat à prix forfaitaire. Les dépendances externes relèvent de la responsabilité de la gestion de projet.
Risque processus : Ces risques concernent principalement l’interne du projet et la planification, le suivi et le contrôle du projet sont alors scrutés de près. Parmi les risques typiques figurent la sous-estimation de la complexité du projet, de l’effort ou des compétences requises. La gestion interne du projet, telle qu’une bonne planification, le suivi de l’avancement et le contrôle, relèvent toutes de la gestion du projet.
Risque produit : Le risque produit représente le principal domaine de préoccupation des testeurs. Ces risques concernent la définition du produit, la stabilité (ou non) des exigences, la complexité du produit et la propension à la défaillance de la technologie.
Désormais, nous nous concentrerons sur les risques produits. Nous emploierons le terme risque produit dans le sens suivant :
Un risque produit représente un mode ou un schéma de défaillance qui serait inacceptable en environnement de production.
Un manifeste du test basé sur le risque
Dans les projets où des risques sont pris (c’est-à-dire tous, selon nous), les testeurs doivent donner de la visibilité sur ces risques à la direction et proposer des méthodes de test fiables pour y répondre tout au long du projet.
Voici la tâche de gestion : réaliser et/ou superviser les actions suivantes du test basé sur le risque :
L’approche classique du risque
Il existe de nombreuses variantes, mais l’approche classique du risque cherche à être quantitative.
Probabilité, conséquence et exposition
Pour évaluer un risque produit, nous devons comprendre quelle est la conséquence de ce mode de défaillance. Si une défaillance se produit, on dit que le risque se matérialise. Nous nous demandons alors « à quel point ce risque est-il sérieux ? », ce que l’on appelle aussi l’exposition.
Pour déterminer l’exposition, nous évaluons le risque selon deux dimensions :
- La probabilité (ou vraisemblance) que le risque se matérialise. Cette valeur est généralement exprimée en pourcentage compris (mais non inclus) entre zéro et 100 pour cent.
- La conséquence (ou impact ou perte) si le risque se matérialise. Il s’agit du coût potentiel des dommages si ce mode de défaillance survient.
L’exposition d’un risque – la gravité d’un risque – se calcule comme le produit de la probabilité et de la conséquence.
Exposition = Probabilité du risque X Conséquence du risque.
L’approche classique du risque manque souvent du soutien technologique nécessaire à une gestion efficace. Les solutions modernes de gestion de tests comblent cette lacune en proposant des fonctionnalités adaptées aux tests basés sur les risques.
Évaluation quantitative ou qualitative
Il est souvent difficile de prévoir le coût potentiel d’une défaillance. Sans information supplémentaire, il est également presque impossible d’estimer avec certitude la probabilité d’une défaillance. C’est pourquoi la plupart des praticiens adoptent des échelles semi-quantitatives ou qualitatives pour la probabilité et la conséquence.
Il est courant d’utiliser des plages numériques de un à cinq pour les deux échelles, ce qui donne des valeurs possibles d’exposition de un à vingt-cinq. Mais peu de testeurs, développeurs ou parties prenantes attribuent ces chiffres avec beaucoup d’assurance, il est donc courant de simplement attribuer un score direct à l’exposition du risque sur une échelle de 1 à 5, ou — plus simplement — une appréciation rouge, orange ou verte. Certains vont jusqu’à se contenter de qualifier les risques d’inclus ou d’exclus du périmètre, mais nous estimons que c’est une simplification excessive.
Que vous quantifiez ou codiez les risques par couleur, l’aspect critique des évaluations de risques n’est pas la notation, mais les discussions et débats lors de l’attribution et l’analyse des scores.
Pour paraphraser Eisenhower, le plan de gestion des risques n’est rien, la planification des risques est tout.
Si l’on vous demande de noter les risques avec une plus grande précision que des échelles de un à trois (ou cinq à la rigueur), vous devriez sérieusement vous demander si la valeur attribuée à ces chiffres est réelle.
Une notation numérique peut donner une illusion de rigueur scientifique, mais si les chiffres sont arbitraires, vous ne trompez que vous-même. Si les écarts de note mettent en évidence des différences d’opinions, par exemple si un utilisateur dit « cinq » et un développeur dit « un ! », alors il convient d’en discuter, car les attentes ou perceptions sont manifestement différentes.
Méfiez-vous d’un simple schéma inclus/exclus du périmètre pour les risques. Il peut sembler clair quels risques doivent être couverts par les tests. Cependant, les projets évoluent, les délais glissent, et des compromis sont nécessaires. Si les risques ne sont pas priorisés d’une manière ou d’une autre, il vous faudra revoir tous les risques identifiés pour décider lesquels ajouter ou retirer du périmètre.
Nous aborderons l’identification du périmètre, la priorisation et l’évaluation plus en détail dans de futurs articles — restez à l’écoute.
Risque produit et test
La discussion autour des risques (produit) mettra en évidence les craintes des parties prenantes concernant la possibilité d’échec dans les domaines critiques du projet ou du système. Une fois que nous avons une liste de risques produit, comment la traduire en actions concrètes et en plans de test spécifiques ? Avant d’y répondre, nous devons mieux comprendre comment le test influence ou modifie notre évaluation du risque.
Les tests n’éliminent pas les risques — ils éclairent leur évaluation
On entend souvent dire que « le test réduit le risque ». Ce n’est pas vrai : le test peut parfois augmenter le risque. Répéter que le test réduit le risque résulte d’une mauvaise compréhension à la fois du risque et du test.
Supposons que nous ayons identifié un risque que telle ou telle fonctionnalité puisse échouer. Nous formulons un test et l’exécutons. Le test peut réussir ou échouer. Comment le résultat influe-t-il sur notre évaluation du risque ?
Premièrement, les tests n’ont aucun effet sur notre compréhension de la conséquence d’une défaillance. La conséquence d’une défaillance est ce qu’elle est et les tests ne la changent pas.
Il existe quatre résultats pertinents d’un test et leur impact sur la probabilité du risque. Ils sont résumés dans ce tableau :
| La probabilité de risque augmente | La probabilité de risque diminue | |
| Le test réussit | Non. Un test réussi ne fait que renforcer notre confiance qu'un mode de défaillance ne se produira pas. (Cela suppose que nos tests soient pertinents). | Oui, avec le temps. Plus nous exécutons de tests qui réussissent, et plus nous explorons de scénarios variés, plus la probabilité de défaillance diminue. |
| Le test échoue | Possiblement, selon l'échec. Mais la probabilité diminue avec le temps. Nous avions prédit que ce mode de défaillance pouvait survenir ; le choix du test est donc justifié. Heureusement, nous pouvons corriger cela maintenant et concentrer nos tests pour réduire le risque d'autres échecs du même type. | Peu probable, sauf si nous avons mal évalué le risque. |
Exécuter des tests associés à un risque particulier nous apporte de plus en plus d’informations pour affiner notre évaluation du risque. Si les tests échouent, notre choix s’avère justifié. Lorsque l’on corrige et que l’on re-teste, à mesure que les tests réussissent, notre évaluation du risque doit diminuer. Mais si l’on continue à découvrir de nouveaux bogues, on peut alors réévaluer le risque à la hausse.
Considérez ceci : si vous exécutez un test et que le résultat n’affecte pas votre appréciation de la probabilité de risque, c’est sans doute un test inutile.
Maintenant que vous comprenez le potentiel des tests pour informer notre appréciation du risque, nous pouvons examiner comment spécifier des tests à partir des descriptions de risques.
Planification de tests basée sur les risques
En tant que testeurs, une fois qu’un risque produit préoccupant est identifié, nous devons formuler un ensemble de tests qui démontrent que ce mode de défaillance est moins probable. Évidemment, notre démarche sera de provoquer ce mode de défaillance de toutes les façons possibles et, ce faisant, nous :
- Rencontrons des échecs, détectons des bogues et les corrigeons (ce qui réduit le risque de ce mode de défaillance), ou
- Constatons des réussites et notre confiance que ce mode d’échec est moins probable augmente.
Collectivement, nos tests ciblent les façons dont un mode de défaillance donné pourrait se produire. Supposons, par exemple, que le risque soit « échec du calcul exact d’une prime d’assurance automobile ». Dans ce cas, un objectif de test pertinent pourrait être « démontrer à l’aide de la technique all-pairs pour les variables d’entrée que le système calcule correctement la prime d’assurance automobile ». Cet objectif de test pourra être remis à un testeur qui élaborera un ensemble de cas de tests de couverture avec la méthode all-pairs, par exemple.
Aspects pratiques
Voici à présent quelques considérations pratiques autour des tests basés sur les risques.
Que faire si les parties prenantes ne souhaitent pas participer à l’évaluation des risques ?
Vous pourriez constater qu’il est difficile d’obtenir la disponibilité des parties prenantes pour vous aider à identifier, évaluer les risques et élaborer votre plan de test.
Que faire s’il existe plusieurs options de test pour un risque produit ?
C’est presque toujours le cas, bien sûr. Par exemple, pour tester une fonctionnalité à risque, vous pourriez utiliser toute une gamme de techniques de conception de test, ou modéliser la fonctionnalité de façon unique et en dériver des tests depuis ce modèle. Il existe toute une gamme de mesures de couverture permettant de fixer un objectif. Vous pourriez tester une fonctionnalité manuellement ou en utilisant un outil ou une autre technologie.
Nous verrons comment faire des choix dans le prochain article, « Combien de tests sont suffisants ? ».
Que faire si les tests (pour traiter un risque) coûtent trop cher ?
Puisqu’il existe (presque) toujours des options et qu’il n’existe aucune limite à la quantité de tests réalisables pour explorer un risque et informer une évaluation, un choix doit être fait. Évidemment, certaines options seront jugées trop coûteuses. Lorsque vous présentez des options aux parties prenantes, il vous faut donc au moins une option abordable et une autre potentiellement hors budget.
Là encore : nous verrons comment faire des choix dans le prochain article, « Combien de tests sont suffisants ? »
Si nous testons davantage les fonctionnalités à haut risque, nous testons moins les autres, n’est-ce pas ?
Si le budget de test est prédéfini pour une équipe, ou si la taille et le nombre de testeurs sont fixes, alors la quantité de tests pouvant être effectuée est limitée (dans un calendrier ou une période limitée). Donc, si nous mettons davantage l’accent sur certaines fonctionnalités, les tests sur d’autres seront réduits. La couverture, ou au moins l’effort consacré par fonctionnalité, varie selon le risque.
L’idée à retenir est que lorsqu’un test échoue et qu’un bogue est détecté dans le système, la sévérité attribuée au bogue sera vraisemblablement bien liée aux conséquences de cet échec (en production). Les bogues les plus graves sont corrigés car ils importent davantage aux parties prenantes.
L’analyse des risques produit permet de mettre en évidence les zones où les bogues, compte tenu de leur importance, seront plus probablement corrigés. Ainsi, en s’appuyant sur une analyse des risques pour déterminer où les tests sont menés (ou renforcés), on maximise la probabilité de trouver des bogues importants, et on minimise la découverte de bogues dans des fonctionnalités qui pourraient avoir moins d’intérêt pour les parties prenantes.
Il serait agréable de penser que parfois nous pouvons tester partout de manière plus homogène. Mais lorsque les ressources et le temps sont limités (et ils le sont toujours, n’est-ce pas ?), une approche basée sur les risques vous aide à utiliser le temps des testeurs de manière plus efficace et efficiente.
Et si le test n’était pas la bonne réponse ?
Avant de vous engager à élaborer une approche de test pour un risque produit en détail, il est important de prendre en compte également les options non liées au test. Par exemple, supposons qu’il existe une grande inquiétude quant au fait qu’un composant système ne fonctionne pas suffisamment bien en production, et que les temps de réponse ou la fiabilité soient médiocres. Bien sûr, vous pourriez réaliser des tests de charge et tenter de déboguer les problèmes. Mais d’autres options pourraient être :
- Acheter le composant auprès d’un tiers, ne pas le construire et éviter le risque.
- Repenser l’architecture de la solution pour répartir la charge sur plusieurs instances du composant.
- Déléguer le traitement à un système batch sur une copie des données.
- Plutôt que d’implémenter une mise en service générale de tous les utilisateurs, adopter une approche progressive en déployant région par région tout en surveillant de près les performances.
- Et ainsi de suite.
Souvent, choisir une action préventive pour éviter que les problèmes ne surviennent est plus efficace et économique que de tester pour les identifier ultérieurement.
Comprendre le rôle de la gestion des risques dans les tests
Les tests peuvent réduire le risque lors de la mise en production. Si nous utilisons une évaluation des risques pour orienter notre activité de test, l’objectif devient explicitement de concevoir des tests pour détecter les défauts afin qu’ils puissent être corrigés et, ce faisant, de réduire le risque d’un produit défectueux.
La détection des défauts réduit le risque résiduel de défaillance en production, où les coûts augmentent très fortement. Lorsqu’un test révèle un défaut qui est ensuite corrigé, le nombre de fautes diminue et, par conséquent, la probabilité globale d’échec décroît.
On pourrait également le voir ainsi : le « micro-risque » lié à ce défaut est éliminé. Mais il faut se rappeler que les tests ne révèlent pas tous les défauts. Il existera donc toujours des défauts latents qui ne sont pas détectés et sur lesquels le test n’a fourni aucune indication directe.
Cependant, si nous concentrons les tests sur les fonctionnalités critiques et détectons des défauts dans celles-ci, les défauts non détectés dans ces fonctionnalités critiques seront moins probables. Les défauts restants dans les fonctionnalités non critiques du système ont une conséquence moindre.
Dernier point : le processus d’analyse de risque est lui-même risqué. L’analyse de risque peut à la fois surestimer et sous-estimer les risques, ce qui conduit à des décisions imparfaites. Si elle va trop loin, l’analyse de risque peut également contribuer à instaurer une culture du blâme.
Parmi d’autres écueils potentiels de l’analyse de risque, il faut bien comprendre qu’il n’existe pas de risque absolu qui pourrait être calculé une fois le projet terminé. Par nature, les risques sont incertains. Tout comme pour l’efficacité des tests, la valeur d’une analyse de risque ne peut être déterminée qu’a posteriori, une fois le projet terminé.
Et c’est tout pour notre manifeste du test basé sur les risques. Le concept réapparaîtra tout au long de la série Leadership in Test, alors restez connectés pour plus d’articles !
Abonnez-vous à la newsletter The QA Lead pour être informé lorsque de nouveaux volets de la série sont publiés. Ces articles sont extraits du cours Leadership In Test de Paul que nous vous recommandons vivement pour approfondir ce sujet et bien d’autres. Et si vous vous inscrivez, utilisez notre code promo exclusif QALEADOFFER pour bénéficier de 60 $ de réduction sur le prix total du cours !
