Développeurs, oubliez les bugs mineurs dans vos tests

Les bugs logiciels : un élément finalement sain

Développer un logiciel sans défaut est certes un objectif noble. Mais finalement cela peut aussi décourager une entreprise d’avoir une démarche honnête en matière de communication. « Minimiser cette capacité à pouvoir divulguer les choses est mauvais pour une entreprise et ses activités », observe Sidney Dekker. Si les équipes partageaient ouvertement les bugs les plus compliqués, elles pourraient en fin de compte identifier de plus gros défauts.

Il y a un juste milieu quand on parle de règles et de méthodes normalisées en matière de contrôle qualité. Les deux créent de bonnes conditions pour sécuriser les logiciels. Cependant, si vous utilisez les mauvaises mesures, vous encouragez un mauvais comportement.

« Cette fascination pour le comptage d'événements négatifs et leur reporting est une illusion », poursuit-il. « Pour comprendre comment des systèmes complexes plantent, il faut agir différemment. »

Les entreprises calculent souvent le nombre de jours sans incident. Dans le développement logiciel, les responsables comptent régulièrement le nombre de jours où les commandes n’ont présenté aucune erreur. Pour Sidney Dekker, ces deux approches sont peu efficaces.

Si un logiciel n’est pas considéré comme parfait, cela ne veut pas dire qu’il n’est pas défectueux. Les entreprises ne doivent pas donner trop d’importance à de petits incidents, surtout si le système peut révéler quant à lui des failles bien plus critiques.

Encourager la culture de la responsabilité

Le point clé suivant est que les développeurs devraient aussi prendre en compte un autre élément : les erreurs récurrentes – ou masquées – qui sont générées même lorsque les résultats sont positifs. Cela demande toutefois quelques contraintes :

• Il faut pouvoir dire "stop" ;
• Reconnaître que ce qui s’est bien déroulé dans le passé n'est pas une garantie de succès dans le futur ;
• Cela nécessite une culture qui tienne compte de la diversité des opinions ; et
• une culture où le risque est omniprésent dans les discussions.

Apprendre de ce qui s’est bien passé

Mettre en place des conditions de feedback adéquates à l’ensemble de l’entreprise permet de réduire les éventuels incidents dans les systèmes complexes. « Si nous voulons comprendre ce qui va mal tourner et les raisons mêmes du problème, nous ne devons pas nous focaliser sur les petits bugs et le comptage d'erreurs », explique encore Sidney Dekker. « Comprendre pourquoi le système fonctionne est la bonne démarche. »

Mais la réalité est qu’il existe bien plus de systèmes qui fonctionnent que d’autres qui ne fonctionnent pas, soutient Erik Hollnagel, professeur d’université au Danemark et expert en matière de résilience. Les entreprises ont en effet tendance à faire des post-mortems le plus souvent lorsque les choses tournent mal.

 « Pour savoir pourquoi les choses tournent vraiment mal, nous devons comprendre pourquoi elles vont bien », ajoute Sidney Dekker. En d'autres termes, les post-mortems doivent aussi identifier ce qui se cache derrière les aspects positifs.

Abraham Wald, que beaucoup considèrent comme l'un des fondateurs de la recherche opérationnelle pendant la Seconde Guerre mondiale, a posé les jalons d’une méthode qui consiste à apprendre d’éléments positifs dans un contexte négatif. Il a par exemple été chargé de déterminer comment optimiser la pose du blindage sur des avions de chasse. Le blindage est un poids mort sur un avion, et les pilotes voulaient le strict minimum pour maintenir ces appareils en vol.

Après avoir mesuré et compté les impacts sur les avions, Abraham Wald et son équipe ont suggéré de mettre le blindage là où il y avait des trous. Ce que font finalement aujourd’hui les développeurs qui concentrent leur attention sur l'endroit où se produisent les bugs. Au lieu de cela, Abraham Wald s'est plutôt rendu compte que le blindage devait être posé là où il n'y avait justement pas de trous. Un exemple à suivre.