Politique de traitement des anomalies

Politique de traitement des anomalies

À première vue, le traitement de bugs est quelque chose d'évident, il faut s'en débarrasser ! Cependant, il semble que se conformer à cette simple politique de traitement des anomalies n'est pas si évident. D'un point de vue économique, le coût annuel de bugs en les US est estimé à 113 000 000 000 $ [État initial 2014], ce qui couvrirait les dépenses d'éléments cumulés déroutants tels que l'éradication de la faim dans le monde et le rachat de célèbres sociétés informatiques. Comment se fait-il qu'il y ait un tel écart entre le coût stupéfiant de bugs et le fait que si peu de choses sont manifestement faites à leur sujet ?

Tout d'abord, les tests semblent être une bonne réponse dans une approche Shift Left (SL), mais étant donné que des tests exhaustifs ne sont pas possibles [ISTQB 2018], certains des bugs sont malheureusement envoyés dans l'environnement de production. Ainsi, SL doit être combiné avec des techniques de Shift Right (SR) afin d'aider les équipes de développement à être réactives pour éviter les problèmes et bug à être traitées par de véritables utilisateurs finaux qui fournissent un retour d'expérience.

Toutefois, il ne suffit pas de réparer les problèmes constatés. Supprimer les effets visibles revient en fait à balayer la poussière sous le tapis et une approche préventive sur bugs est clairement beaucoup plus efficace. Un moyen de parvenir à une stratégie proactive consiste à effectuer une analyse des causes profondes (RCA). Elle vise à trouver la source d'un problème et à supprimer la racine qui en est à l'origine. Cette stratégie peut être encore plus efficace si elle est combinée à une analyse Pareto afin de se concentrer sur les 20 % de bugs qui causent 80 % des problèmes. Cela devient possible lorsque vous commencez à faire la différence entre les incidents(un événement défini comme une interruption non planifiée d'un service ou une réduction de la qualité d'un service [Axelos 2019]) et les problèmes(une cause, ou une cause potentielle, d'un ou plusieurs incidents ; une erreur connue qui a été analysée mais n'a pas été résolue [Axelos 2019]) : lorsque vous résolvez un problème, plusieurs incidents ne se produiront plus et le problème est une cause profonde d'un incident. Néanmoins, la RCA n'est pas une solution miracle car

• elle conduit à des analyses longues et complexes qui nécessitent des experts, des plans d'action et des documents ; la quantité de travail croît probablement de façon exponentielle avec la complexité du système
• elle n'est pas facile à mener - l'utilisation des "5 questions" ou d'un Ishikawa peut conduire à de fausses hypothèses ou à des solutions hors de portée (après tout, tout est censé être causé par un Grand Architecte de l'Univers !)
• les causes peuvent tourner en boucle - il n'y a alors pas de racine mais un système de multiples causes entrelacées [Appelo 2010], en particulier dans les systèmes complexes [Snowden 2007].

Ce dernier point peut être expliqué par l'effet papillon de Lorenz [Lorenz 1963] qui a conduit Lorenz à affirmer que le battement d'aile d'un papillon au Brésil peut provoquer une tornade au Texas dans le sens où "au fil des ans, de minuscules perturbations n'augmentent ni ne diminuent la fréquence d'occurrence de divers événements météorologiques tels que les tornades ; le plus qu'elles puissent faire est de modifier la séquence dans laquelle ces événements se produisent" [Lorenz 1995]. En d'autres termes, le battement d'aile ne génère pas à lui seul la tornade, mais il contribue au phénomène catastrophique. Dans les systèmes complexes, les incidents et les catastrophes sont en fait la conséquence d'une série de négligences qui ont été alignées pour laisser l'événement et ses conséquences se terminer mal [Reason 2006] ; chaque étape de l'incident peut voir son ampleur devenir suffisamment importante pour devenir une anomalie visible ou même une catastrophe [Moustier 2019-1]. Cette compréhension permet de voir que même si la situation semble désespérée, il existe des possibilités, comme la résolution de problèmes mineurs [Appelo 2010] tout comme la théorie des fenêtres brisées qui vise à résoudre les problèmes petit à petit. Ce point de vue conduit à l'importance d'exécuter 5S sur le code, sur la documentation et les cas de test et de résoudre les problèmes rapides dès qu'ils apparaissent selon une approche Kaizen.

Pour faciliter le traitement de bugs et limiter la complexité du grand désordre en cours, le "Bug Cap " de Microsoft peut être impliqué [Bjork 2017]. Lorsque la quantité de bugs dépasse un seuil supérieur, l'équipe s'attache à les éliminer jusqu'à ce qu'un seuil inférieur soit atteint, à la manière d'un phénomène d'hystérésis [Moustier 2020].

‍

Dans le même état d'esprit, mais à un niveau plus élevé, la gestion du budget d'erreurs de Google généralisé à la dette technique permettra de traiter le nombre de "fenêtres brisées" sur tous les aspects et de garder le désordre sous un contrôle relatif.

En dehors de toute technique permettant de résoudre les problèmes dans un état d'esprit de plus avec moins, il semble que la culture influence la façon dont bugs est traité [Westrum 2004]. Lorsque la culture est favorable, les enquêtes et la RCA sont des tactiques couramment utilisées. Finalement, si la culture n'est pas assez proactive, les problèmes sont au moins résolus globalement, là où ils existent (par exemple, inspecter chaque avion pour vérifier un problème trouvé sur un avion). Dans les organisations moins efficaces, les corrections peuvent être effectuées uniquement au niveau local . Toujours dans le sens de l'immaturité, les défauts peuvent même être atténués par une communication avec les relations publiques qui contextualise l'anomalie pour en réduire l'impact. Dans son enquête, Westrum a également noté que certaines cultures peuvent aller encore plus loin dans le traitement de bug en isolant le message qui parle du problème, cette étape est appelée "Encapsulation". Enfin, l'action ultime consiste à traiter le problème en supprimant, en nuisant ou en arrêtant le message qui met en lumière l'anomalie en "tirant sur le messager". Ces deux dernières situations extrêmes peuvent sembler insensées, mais il y a eu une tentative dans une entreprise bien connue de l'industrie du transport aérien. Dans cette entreprise, des "Bug Bashing Days " étaient organisés, de petits cadeaux et des bonbons étaient offerts pour permettre aux développeurs d'éliminer les problèmes en une journée dans la bonne humeur. Au bout d'un certain temps, les cadres supérieurs ont fini par mettre un terme à cette initiative, car certains responsables "encapsulaient" les correctifs jusqu'à l'événement, afin d'obtenir un bon classement. Lorsqu'il s'agit de prendre la responsabilité d'un bug qui peut brûler la carrière de quelqu'un ou de toute autre situation à fort enjeu, il est désormais plus facile d'imaginer un traitement consistant à"tirer sur le messager".

‍

Impact sur la maturité des tests

Kaizen nous apprend à résoudre les petits problèmes dès qu'ils apparaissent, à condition de chercher les problèmes en premier lieu, conformément au premier principe de test "Les tests montrent la présence de défauts" [ISTQB 2018] ! Cela conduit à multiplier les types de tests sur la solution notamment avec les éléments suivants ENF à tester ou Monitoring de la solution pour être au courant des problèmes dès qu'ils apparaissent ou encore repérer les situations qui conduisent à des défaillances pour limiter les indisponibilités.

Les équipes peuvent également essayer de tester la résilience du système en perturbant volontairement les techniques et les outils du système. Lorsque vous considérez le système dans son ensemble, vous pouvez également envisager la façon dont les équipes réagissent lorsqu'un problème apparaît de façon inattendue et choisir une stratégie de test "d'inversion" comme dans les tests de sécurité. Dans de telles situations, la capacité de faire Andon et de voir comment les équipes se rassemblent rapidement autour du problème, notamment grâce à un processus 8D, peut être très utile. Task Force US notamment grâce à un processus 8D peut être vraiment intéressant pour voir comment les problèmes sont traités de manière efficace et efficiente. De ce point de vue, il devient désormais culturellement possible de "compter" correctement bugs dans un produit. Dans les entreprises qui perturbent le système pour améliorer sa résilience, il est éventuellement acceptable de ne pas corriger les bugs connus. La technique de "marquage et recapture" de l'écologie permet ainsi d'estimer la taille d'une population animale. Cette science fournit plusieurs modèles de marques de programmes pour des estimations précises [Hoffman 2015] [Fishbio 2020] [Hightower 1984].

Lorsque bugs devient difficile à trouver en interne, l'organisation peut également faire appel à des personnes extérieures pour la découverte de bug . Cette approche est appelée "Bug Bounty ", souvent rencontrée en cybersécurité [Malladi 2019] ou" Crowdtesting" pour les tests fonctionnels ou de compatibilité . Cette politique de gestion de bug est généralement basée sur des récompenses financières liées à la gravité de bug et serait particulièrement efficace pour la chasse aux bugs difficiles à trouver [Bacchus 2017].

Le point de vue d'Agilitest sur cette pratique

Lorsque l'automatisation des tests est systématiquement utilisée pour générer des critères d'acceptation conformément à l'ATDD, bugs peut alors être créé automatiquement à partir du cadre d'automatisation, mais le phénomène des faux positifs écarte généralement cette idée des testeurs.

Cependant, l'automatisation des scripts de test empêche naturellement la régression. Cette sorte de propriété intrinsèque devrait conduire les équipes à automatiser des scripts qui vérifieraient que tout bug corrigé ne réapparaîtrait pas. Cette stratégie est appelée "Defect-Driven Testing" (DDT) [Richardson 2005] et devrait faire partie d'une politique de traitement de bug [Crispin 2009].

‍

Pour découvrir l'ensemble des pratiques, cliquez ici.

‍