Gérer le risque par les tests vs. La Covid-19

Dans cette période de crise sanitaire, on nous parle beaucoup de risques. Le risque de contamination, de transmission ou de développement de symptômes graves. Cette notion est également très présente dans le test logiciel et encore plus lorsqu’il s’agit de qualité logicielle. En effet, selon le contexte, et surtout la criticité, l’effort de test sera fortement influencé par… Le risque bien sûr !

Prenons par exemple, un jeu gratuit que l’on installe sur les smartphones. Avant d’arriver sur vos appareils, et même s’il est gratuit, en principe ce jeu a été testé par l’équipe l’ayant réalisé. Admettons qu’il s’avère complètement défectueux, qu’il plante 2 lancements sur 3 et que le nombre de points affiché ne soit pas du tout cohérent avec la partie. Bref, il ne fonctionne pas du tout ! Vous abandonnerez le jeu et cela n’aura aucun impact sur le reste de votre vie.

D’un autre côté, prenons l’exemple du logiciel d’aiguillage des trains. Imaginons que celui-ci fonctionne mal et qu’il donne l’autorisation en même temps à deux trains de s’engager sur une même voie. Il y a un fort risque que les trains entrent en collision si elles se présentent en même temps à l’endroit de convergence ou si le premier train circule plus lentement que le second. En tant que passager d’un de ces trains, l’accident occasionné par le logiciel défectueux aura des impacts sur votre intégrité physique et vous marquera à vie.

Et c’est là qu’intervient le risque. Il s’agit de la combinaison de la probabilité qu’un événement négatif ou indésirable survienne et la gravité des conséquences de cet événement.

Pour ce qui est de la Covid-19, le risque de contamination réside dans la probabilité de transmettre le virus (ou de le contracter) et de la réaction de l’organisme. Selon les personnes, les dispositions prises permettent de réduire la probabilité d’être contaminé et de réduire la gravité des symptômes. Certains malades meurent quand d’autres sont malades sans le savoir.

Mais alors, en test logiciel, comment faire face aux risques auxquels le produit est confronté ?

Pour ce faire, procéder en 4 étapes : identifier les risques potentiels, évaluer chacun de ces risques, modérer les risques et enfin, traiter les risques.

Des normes comme l’IEC 61508 mettent à disposition des matrices permettant de quantifier un risque selon des échelles et définit ainsi 4 niveaux de criticité des systèmes, appelés SIL (« System Integrity Level »). Par exemple :

Une échelle de probabilité : Invraisemblable (1), peu probable (2), probable (3), certain (4).

Une échelle de criticité : Anecdotique (1), peu impactant (2), impactant (3), catastrophique (4).

Détermination du niveau de risque

 AnecdotiquePeu impactantImpactantCatastrophique
InvraisemblableIIIIIII
Peu probableIIIIIIIII
ProbableIIIIIIIIV
CertainIIIIIIVIV

Identifier les risques

Comme pour la crise du coronavirus, dresser la liste des risques potentiels :

  • Être une jeune personne en bonne santé et se faire contaminer dans une rue déserte (A).
  • Être une jeune personne et se rapprocher d’un contaminé (B).
  • Être une personne âgée présentant des pathologies respiratoires et rester à plus un mètre sans masque de tout autre individu (C).
  • Être une personne âgée présentant de multiples pathologies et rester à proximité d’une personne contaminée (D).

Dans votre logiciel, plus du code ou une règle métier est complexe et plus il est probable d’y trouver un défaut. De même, plus la fonctionnalité est utilisée par son utilisateur (ou qui n’a pas de fonctionnalité équivalente) et plus la présence d’une anomalie serait bloquante. C’est le cas si un utilisateur ne peut pas se connecter à l’application par exemple.

Évaluer les risques

A partir d’une matrice comme celle présentée plus haut il est simple d’évaluer un risque. Il faut toutefois bien estimer sa probabilité d’occurrence et penser à tous les impacts possibles.

Si nous reprenons nos exemples plus haut :

  • A : Se faire contaminer dans une rue déserte est invraisemblable (1), et la personne étant jeune et en bonne santé, les symptômes seront donc anecdotiques (1). Le niveau de risque est donc de I.
  • B : Le fait que la personne se rapproche d’un contaminé fera qu’elle le sera probablement aussi (3). La personne étant jeune et en bonne santé aura alors des symptômes peu impactants (2). Le niveau de risque est donc de II.
  • C : Se tenir à plus d’un mètre de toute autre personne rend la contamination peu probable (2). Néanmoins, les conséquences peuvent être impactantes (3) puisque la personne est âgée. Le niveau de risque est donc de III.
  • D : Rester de façon prolongée proximité d’un malade augmente largement la probabilité d’être également contaminé, c’est certain (4). De plus, la personne étant âgée et déjà atteinte de multiples pathologies développera des symptômes catastrophiques (4). Le niveau de risque est donc de IV.

Réduire les risques

Selon le niveau global du risque, il existe 6 façons de le réduire, voire de l’anéantir.  Depuis le début de la crise sanitaire nous avons vu de nouvelles pratiques qui correspondent à la gestion du risque se mettre en œuvre.

Accepter le risque : dans ce cas de figure, la population française a pris connaissance de l’existence de ce virus. Nous savions qu’il se trouvait en Chine mais nous ne nous sentions pas encore concernés. Ce n’était à l’époque qu’une vague menace et nous acceptions ce risque.

Pour un logiciel, aucun effort de test n’est prévu pour une fonctionnalité. Le testeur estime que l’effort de test serait plus élevé que les impacts d’une éventuelle anomalie. L’analyse de risque révèle que la fonctionnalité est simple et sa panne serait transparente pour les utilisateurs. Ne pas tester est donc pleinement assumé par l’équipe. Dans ce cas de figure, l’équipe devrait se questionner sur la valeur délivrée par ladite fonctionnalité et l’intérêt pour elle de la réaliser.

Prendre des précautions : au mois de février 2020, le pays prend conscience que le virus pourrait arriver sur notre territoire et concerner les français. Même si aucune personne n’a officiellement été contaminée ni décédée, par précaution, les personnes arrivant de Chine ont été mises en quarantaine à leur arrivée en France.

Pour un logiciel, par précaution, l’équipe met en place quelques tests sans pour autant y allouer une charge importante. Les conséquences d’un dysfonctionnement ne seraient pas dramatiques, mais un test permettrait de rassurer toute l’équipe.

Prévenir le risque : lorsque la menace s’est faite sentir, les autorités sanitaires françaises ont diffusés des spots télévisés et radios prévenant qu’un risque de contamination existe et demande aux personnes d’appliquer des gestes barrières afin de réduire la probabilité de contamination.

Pour un logiciel, l’équipe prévient le risque en le testant dès que possible et chacun alerte les autres membres dès que la probabilité d’un défaut devient significative. Cela pour mieux cibler l’effort de test. C’est le cas par exemple d’une règle métier complexe où un oubli ou une erreur est très probables. Des méthodes comme de la revue de code ou de l’analyse statique sont de bons moyens pour prévenir les risques.

Protéger (les personnes) : en faisant cela, on cherche à réduire les impacts sur les gens. Pour cela des dépistages massifs ont vu le jour permettant aux malades d’être pris en charge rapidement et ainsi empêcher que la maladie ne s’aggrave pour les personnes contaminées.

Concernant le test logiciel, comme pour la prévention du risque, le testeur va augmenter son effort de test lorsqu’un disfonctionnement de l’objet de test devient critique. C’est le cas par exemple d’une fonctionnalité clé ou incontournable pouvant conduire à un abandon du produit de la part de l’utilisateur. C’est le cas du système (logiciel) de freinage d’un véhicule où la tolérance aux pannes est proche de 0.

Déléguer le risque : lorsque le risque atteint un certain niveau, il ne peut plus être assumé par une seule entité. Les autorités françaises mettent en place des actions contre la pandémie et fait appel à la responsabilité de chacun pour limiter la propagation du virus. En 2020, chaque citoyen a sa part de responsabilité dans propagation du virus.

Pour un logiciel, certains tests peuvent demander soit une expertise dans un domaine comme la sécurité ou la performance, soit des moyens techniques importants comme une large combinaison d’appareils mobiles. Dans ce cas, l’équipe externalise la gestion ou l’exécution de ses tests.

Se désister : il s’agit là d’abandonner le risque car son niveau est au maximum. L’état français a confiné toute la population et abandonne l’idée que les personnes ne soient en contact. Autrement dit sauf pour raison de première nécessité, la responsabilité de contaminer une personne revient à la personne qui se déplace.

En matière de logiciel, lorsque le risque est trop important et qu’il ne peut être suffisamment réduit, l’équipe peut abandonner l’idée de développer sa fonctionnalité. Celle-ci pourrait alors être transformée mais il ne s’agit plus de la fonctionnalité initiale.

Traiter les risques

Selon le niveau du risque (de I à IV) et de sa nature, le testeur mettra en œuvre un plan d’actions de façon à ce que le risque soit réduit au maximum. Que ce soit en réduisant la probabilité d’occurrence ou la sévérité lorsque le risque se produit, le testeur détient plusieurs outils pour gérer ses risques. Ces outils étant les différentes techniques, niveaux et type de test.

Durant le cycle de vie du produit, les risques identifiés vont évoluer. Il conviendra à l’équipe d’organiser plusieurs ateliers dans le temps afin de réévaluer les risques. Certains peuvent augmenter, d’autres réduire voire disparaitre et de nouveaux risques peuvent apparaitre.

Conclusion

Finalement une crise sanitaire c’est un peu comme un système logiciel. On est confronté à un risque alors on teste. Selon le niveau de risque il convient d’adopter la bonne posture pour qu’à la fin le résultat obtenu soit satisfaisant. N’oublier aucun risque et penser à tous les impacts sera le plus difficile dans cette démarche.

2 Responses

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Automatisation

Automatiser ses tests avec Agilitest

Agilitest en Bref Agilitest est un outil d’automatisation IHM en KDT qui a fait l’objet d’une présentation détaillée de sa première version dans la taverne. Le postulat d’Agilitest est que l’automatisation est complexe et demande des compétences techniques que les testeurs n’ont pas forcément. La compétence « automatisation » est donc relativement

Lire la suite »
Livrable

Les plans de test

Définition ISTQB : un document décrivant l‘étendue, l‘approche, les ressources et le planning des activités de test prévues. Il identifie entre autres les éléments et caractéristiques à tester, qui fera chaque tâche, le degré d‘indépendance des testeurs, l‘environnement de test, les techniques de conception des tests et les techniques de mesure

Lire la suite »
ISO 25010

Duel: tests système vs tests fonctionnels

Introduction Lorsque l’on aborde le sujet des niveaux de test on cherche des exemples pour chaque niveau. Il est possible de faire une analogie mais, dans le cas contraire, il y a souvent des raccourcis qui sont faits. Si le raccourci tests de composant/tests unitaires fonctionne généralement assez bien il

Lire la suite »