[Programmez] Comment prédire et prévenir les anomalies ?

La prévention des bugs, la capacité de les anticiper et de les détruire avant même qu’ils n’apparaissent est un Graal pour un bon nombre de testeurs, de développeurs… mais aussi de responsables de SI ou de sociétés éditrices de logiciel.

Non, je ne parle pas de Minority Report mais plutôt d’études statistiques basées sur des mesures. Pour cela il faut, comme souvent, s’intéresser à d’autres domaines. Je propose aujourd’hui de se pencher sur la fouloscopie et l’étude du comportement des malfaiteurs. Cet article a été inspiré suite au visionnage de cette vidéo < https://www.youtube.com/watch?v=HHCiNPtR1NI&t > qui nous permet d’imaginer 2 manières ou types d’algorithmes pour prédire les bugs.

Il va sans dire que prédire les défauts/bugs/anomalies est la mise en application ultime du principe du test « Tester tôt ».

1ère méthode : se baser sur l’historique

Cette méthode est basée sur de calcul des risques d’occurrence de délits (cambriolage, agression…). Pour calculer cela la chercheuse Andréa Bertozzi s’est inspirée du modèle des séismes en partant du principe que la majorité des délits, comme pour les séismes, ont plus de chance d’arriver suite à un autre délit (ou séisme) et donc d’être des répliques. Cette proximité temporelle et spatiale des délits peut sembler « logique » lorsque l’on considère que les crimes sont impactés, au moins en partie, par 3 critères :

• Le premier est le principe des « suiveurs », il est possible de commettre un vol dans cette rue, je vais donc le faire également.
• Le deuxième est plus un aspect méthodique du voleur qui travaille secteur par secteur en finissant un quartier avant de passer à un autre.
• Le troisième est l’effet de « modèle », je pense ici aux « copycats », des fans de criminels qui reproduisent le comportement criminel par admiration, intérêt ou simplement pour exister.

En partant de ce principe Andréa Bertozzi a repris l’équation permettant de prédire les séismes pour l’appliquer au crime, le crime appelant le crime…

Les résultats de cette équation permettent de donner en amont non pas des crimes mais des risques de crimes. Cela donne l’équivalent d’une « météo du crime ». Les expérimentations sur le terrain à travers des applications développées à partir de cette équation tendent à montrer une bonne efficacité de ce système qui au final ne fait pas appel à de l’intelligence artificielle !

Il est intéressant de noter que, comme pour la météo, les prévisions proposées ne sont jamais fiables à 100%. De même, plus la prédiction est éloignée dans le futur, moins elle est fiable. Les risques donnés par l’algorithme ne sont valables qu’à court terme et diminuent fortement au fil des jours si aucun autre délit n’est commis.

Quelle application dans le monde du test ?

Quel rapport avec le test et plus précisément les bugs ?

Le regroupement des crimes peut être considéré comme une application du principe du regroupement de défauts ! Tout comme pour les séismes, les champignons et le crime, les bugs sont souvent regroupés. Lorsque l’on détecte une anomalie, il y a de fortes chances d’en détecter une autre à proximité. Cette proximité peut être liée à des faiblesses inhérentes au logiciel à un contexte comme une utilisation spécifique et temporaire, l’arrivée de nouveaux utilisateurs, une nouvelle de manière d’appréhender le logiciel ou encore à des changements liés à un développement commun… De manière générale, dans un logiciel il y a souvent des parties sensibles qui sont plus impactées que les autres par les anomalies. Ce type de bugs est d’ailleurs assez bien repéré par les testeurs lors des sessions de tests exploratoires.

Concrètement, en partant de ce principe, il est possible de contribuer à la prédiction du risque de défaut. Cela pourrait par exemple se traduire par :

• Etablir une cartographie sous forme de réseau de relations (comme pour les réseaux sociaux) entre les différentes fonctionnalités ou les différents composants. Chaque bug détecté augmentant le risque de défaut pour une durée de X (nombre à définir en fonction du contexte) sur la (les) fonctionnalité(s) ou le(s) composant(s) impactés par celui-ci. Cette cartographie du risque permettrait de sélectionner différemment les tests.
• Une analyse des résultats des tests et des anomalies remontées par ces derniers pour définir des probabilités d’échecs de chaque test et donc aider à la sélection et la priorisation.
• Une analyse des commits et du code modifié pour tenter de dégager des similitudes entre les différents commits ayant engendrés récemment des anomalies.
• Etablir une cartographie par type d’utilisateur impacté sur les bugs détectés afin de proposer une cartographie des risques par personae et de définir ou orienter ses tests en fonction…

A noter, pour toutes les solutions proposées l’IA peut proposer une aide précieuse pour analyser un grand nombre de données. Elle n’est cependant pas indispensable et est sujette à de nombreux biais. Il faut se rappeler qu’elle reste principalement un outil d’aide à la décision.

Le principe du regroupement de défaut et plus particulièrement l’analyse des commits pour une détection au plus tôt des anomalies sont d’ailleurs un axe de recherche très important dans le domaine du test et plus particulièrement de l’IA au service du test. Altran a d’ailleurs lancé avec Microsoft < https://www.microsoft.com/en-us/AI/ai-lab-code-defect > une communication sur l’algorithme de détection des anomalies lors d’un commit. On est ici sur une IA qui analyse un grand nombre de paramètres d’un commit pour prédire un risque d’introduction d’anomalie. Cela se calcule grâce aux commits précédents et leurs résultats (défectueux ou non). L’algorithme fait un ensuite un rapprochement entre les variables des différents commits pour donner son résultat.

2ème méthode : protéger les « proches » à la suite d’un bug

Cette méthode prend racine dans l’analyse des guerres de gang et une analogie avec l’épidémiologie. Elle part du postulat que les assassinats « volent en escadrille », c’est à dire qu’il y a des périodes de calme et des périodes avec une suite d’assassinat (on s’en aperçoit malheureusement aussi avec les attaques terroristes…). Des études ont montré que les assassinats pouvaient être modélisés comme des épidémies avec un R0 < https://fr.wikipedia.org/wiki/Nombre_de_reproduction_de_base >fort heureusement inférieur à 1.

Pour faire simple, il y a une « victime alpha ». Cette victime alpha peut transmettre sa « maladie » (se faire assassiner) pendant une période de « gestation ». Au-delà de cette période, les chances des relations de la « victime alpha » de se faire assassiner reviennent à la normale. Si, au contraire, pendant cette période de gestation des contacts de la victime alpha se font assassiner alors la chaîne de propagation probable s’étend aux contacts des contacts assassinés… On voit bien ici que l’on est très proche des problématiques que l’on retrouve avec les maladies infectieuses (et la Covid 19 ^^).

Afin de diminuer ce nombre d’assassinats (dans la vidéo ayant inspiré cet article, on parle de chaîne dépassant les 30 homicides). Comme pour une épidémie, il « suffit » de briser la chaîne de propagation. Avec le Covid-19, on détecte les personnes infectées (c’est plus simple avec les assassinats) puis on gère les « cas contacts » en leur demandant de se faire « tester ».

Il est intéressant de faire le parallèle avec le logiciel ! Ce type de raisonnement reprend également le regroupement de défauts vu précédemment mais l’applique autrement. Ici, le proche, ce sont les contacts du composant, les fonctionnalités échangeant avec le composant, la partie de code ou la fonctionnalité impactée par l’anomalie. De même, cela se rapproche également du rôle des campagnes de régression qui suite à un changement non parfaitement contrôlé, se met à son tour à impacter d’autres zones du logiciel… A la différence que pour la régression ce qui déclenche les vérifications n’est pas une anomalie mais une modification du logiciel.

Encore une fois cette théorie semble donc cohérente lorsque l’on parle de logiciel. Lorsqu’une fonctionnalité a des anomalies, elle impacte forcément d’autres fonctionnalités avec lesquelles elle échange… Ou encore des fonctionnalités qui ont des parties de code communes. Ces mêmes autres fonctionnalités seront impactées par un changement sur la première et ce, même si la modification est un correctif. Il arrive fréquemment que des modifications soient faites sur un logiciel pour s’adapter à un bug. Lorsque ce bug est corrigé, notre logiciel n’est peut-être plus à même d’analyser correctement l’information.

Quelle application dans le monde du test ?

Concrètement on s’oriente ici plus sur de la prévention de défaut. L’utilisation d’une logique similaire pourrait, par exemple, prendre la forme de la mise en place d’un « protocole sanitaire » après la découverte et la correction d’un bug. Ce protocole pourrait alors ressembler à celui ci-dessous:

1. Corriger l’anomalie
2. Identifier et prévenir les « contacts » du code, du composant et/ou de l’anomalie
3. Tester les cas contacts, pour assurer que ces contacts ne sont pas infectés ou que la correction n’a pas introduit d’autres anomalies
4. Corriger les anomalies des cas contacts infectés
5. Identifier les contacts des cas contacts infectés
6. Tester les contacts des cas contacts infectés…

Cela permet de prioriser des tests en fonction de risques avérés et de prévenir des défauts. Là encore on n’est pas forcément sûr de l’IA même si cette dernière peut fortement nous aider à identifier les « contacts ».

3ème méthode : empêcher l’apparition de foyers infectieux, assurer un « sentiment de sécurité »

Toujours dans le domaine de la criminalité, on trouve une autre théorie qui mérite notre attention. Elle est nommée « Hypothèse de la vitre brisée ».

Cette théorie montre que ce n’est pas la délinquance qui engendre le sentiment d’insécurité mais plutôt les incivilités. Elles engendrent un sentiment d’impunité favorable au passage à l’acte car ce modèle montre que la criminalité émerge de petits détails qui transforment un quartier paisible en une véritable jungle.

Cette approche montre qu’une attitude de renforcement des liens sociaux est plus efficace qu’une augmentation des effectifs de police. Des solutions permettant aux citoyens de se sentir plus en sécurité pourraient donc être :

• La mise en place de policiers dans les zones problématiques dont la principale mission serait d’être présent et de connaître la population
• Avoir des agents à l’écoute des plaintes des citoyens
• Prendre en compte des retours des citoyens et résoudre les problèmes remontés

De même, on s’aperçoit que le nombre est parfois plus problématique que l’impact réel des problèmes vus par les habitants. On parle ici de « sentiment d’insécurité ». Par nombre il faut entendre ici le nom concret d’actes d’incivilité mais aussi le nombre de fois où l’on passe devant le résultat d’une de ces incivilités comme, par exemple, une voiture brûlée qui reste des semaines dans une allée passante.

Quelle application dans le monde du test ?

Concrètement, on est ici plus à un niveau de gestion de la qualité et plus particulièrement de la qualité ressentie par les utilisateurs. Ainsi, plutôt qu’augmenter l’effort de test appliqué une fois les bugs apparus, il est plus efficace de traiter et éviter les petites « incivilités ». Pour cela, des approches à fortes valeurs ajoutée telles que :

• La mise en place de mesures en production (shift right) afin de repérer rapidement des anomalies.
• Avoir un support disponible et à l’écoute des utilisateurs
• Corriger en priorité les anomalies remontées par les utilisateurs et communiquer lors de leur correction.

De même, il est possible dans le logiciel de lutter contre le « sentiment d’insécurité » qui dans ce cas serait plus un « sentiment de mauvaise qualité ». Dans ce cas, la mise en place de bonnes pratiques liés à la qualité peuvent être des solutions. Ces bonnes pratiques peuvent être :

• Le Software Craftsmanship avec du refactoring de code régulier et maîtrisé par du TDD et combiné à l’ATDD
• L’implication des tests au plus tôt notamment avec des ateliers de type « 3 Amigos » pour obtenir de « bonnes » US
• Une socialisation renforcée par exemple avec du pair programming voire du mob programming et plus généralement avec des équipes de type X-Team, équipes améliorées qui intègrent des activités de réseautage et des rôles d’ambassadeur auprès d’autres équipes, des clients et des experts.

Conclusion

Prédire efficacement les bugs à 100% est impossible. C’est également le cas pour les séismes, les délits et les homicides. Néanmoins il existe des méthodes efficaces permettant d’évaluer des risques de séismes, délits et homicides et donc de savoir quelles actions mettre en place pour les diminuer. Les modèles proposés sont, au moins partiellement, transposables au monde du test logiciel et plus précisément du bug. L’utilisation de ces méthodes (sans nécessairement avoir recours à de l’IA) permettrait de détecter plus tôt des anomalies, limiter des chaînes de propagation en proposant l’équivalent d’une « météo » des anomalies qui donnerait un taux de risque de présence ou d’introduction de bugs.

Merci à Benjamin Butel, Christophe Moustier, Olivier Denoo et Michael Granier pour leurs contributions à cet article.

Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles

N’hésitez pas à faire vos propres retours d’expérience en commentaire.