CINQUANTE NUANCES DE BUGS

404 error. Rien de tel qu’un bug pour énerver, n’est-ce pas ? Mais qu’est-ce qu’un bug exactement ? Et quelle est la différence avec une anomalie, une erreur, un défaut, une défaillance ? Si vous aussi, vous êtes un peu perdus, on vous propose un petit guide pour mieux comprendre toutes les nuances de bugs. 

Savez-vous d’où vient le mot « bug » ? Si ce mot anglais signifiant « insecte » en français a été choisi pour désigner un problème informatique, ce n’est pas un hasard. C’est l’inventeur Thomas Edison qui a utilisé ce terme en premier. D’après l’informaticienne Isabelle Collet (Les oubliées du numérique), Thomas Edison aurait découvert une panne dans son phonographe, qu’il aurait ainsi comparé à un insecte imaginaire dissimulé à l’intérieur de son appareil, responsable du problème. 

Soixante ans plus tard, alors que des scientifiques travaillent sur le Mark II, l’ordinateur électromécanique qui succède au Mark I (le premier calculateur numérique d’IBM créé aux Etats-Unis), un incident a lieu. Grace Hopper, une ingénieure qui fait partie de l’équipe, relate l’histoire dans le carnet de bord de l’ordinateur. « À la date du 9 septembre 1947, on peut voir, collé sur la page, le cadavre d’un insecte qui avait volé dans un commutateur et s’était retrouvé coincé », explique-t-elle. Sur la page, sous l’insecte, une petite note manuscrite mentionne alors « le premier cas de bug recensé ». 

Mais qu’est-ce qu’un bug, exactement ? 

À la toute base, le bug désignait donc une défaillance technique, une panne informatique, provoquée par un court-circuit, par exemple. Mais depuis, sa signification a beaucoup évolué. 

Aujourd’hui, le bug désigne surtout un dysfonctionnement. En d’autres termes, on peut estimer qu’il y a un bug dès lors que le comportement du programme ou du logiciel ne correspond pas au résultat attendu. Il peut être dû à un problème informatique, comme à une erreur dans l’écriture du programme. 

À titre d’exemple, dans le cadre d’une application ou d’un site, on parle de bug lorsqu’un bouton n’apparaît pas ou lorsqu’il ne se passe rien quand on clique dessus, lorsque l’application s’arrête brusquement, lorsque la couleur du texte n’est pas la bonne, lorsque le prix du produit affiché n’est pas le même que celui dans le panier, ou encore lorsque le panier se vide quand on se connecte à son compte. 

Et encore, ce n’est qu’un petit échantillon des bugs qu’il est possible de rencontrer.

Bug, défaut, anomalie, défaillance, même bateau ? 

Mais quelle est la différence entre un bug, une anomalie, un défaut, une défaillance ? En réalité, on pourrait dire que le terme bug est un terme générique, qui englobe plusieurs niveaux, selon la conséquence introduite. 

>> Un défaut : il s’agit généralement d’une simple divergence par rapport aux spécifications déterminées en amont. Cela peut être un défaut graphique, lorsque la couleur affichée n’est pas la bonne ou lorsqu’il y a un décalage dans les blocs visuels. Mais il peut aussi s’agir d’un défaut de rédaction, lorsqu’un mot est mal orthographié ou ne correspond pas à celui qui avait été choisi pour désigner tel ou tel bouton. Attention, un défaut ne mène pas forcément à une anomalie ou à une défaillance et cet article de La taverne du testeur l’explique d’ailleurs très bien !

>> Une anomalie : il s’agit ici d’un défaut qui perturbe de manière négative et impactante le fonctionnement du logiciel et peut donc affecter son utilisation. Ce dernier peut ne pas réagir comme il est censé réagir selon les exigences des spécifications, les documents de conception, etc, ce qui peut être problématique. Un bouton qui ne marche pas ou qui renvoie sur la mauvaise page, un panier qui se vide, une impossibilité de se connecter à son compte peut être désigné comme une anomalie.

>> Une défaillance : il s’agit ici du niveau de bug le plus élevé. Cela implique qu’une partie du logiciel ou sa totalité est inutilisable, soit parce qu’il ne fonctionne pas, soit parce que son comportement diffère de façon trop importante par rapport à celui qui est attendu et cela le rend donc inexploitable. 

Et quid des incidents ? Des erreurs ? 

Dans le monde du test, vous pouvez aussi entendre parfois parler d’incident ou d’erreur. Quelle est la différence avec les bugs, vous demandez-vous peut-être ? 

C’est simple. Un incident correspond à un problème qui a été trouvé lors de l’exécution d’un test. En d’autres termes, le test est tombé en échec car il a repéré une divergence dans le comportement attendu (défaut), mais on ne sait pas encore pourquoi. Il peut s’agir d’une anomalie ou d’une défaillance comme d’un faux-positif, c’est-à-dire lorsqu’un défaut est rapporté alors qu’en réalité il n’existe pas dans l’élément testé. Il faut ensuite aller reproduire le parcours à la main pour vérifier ce qui a provoqué l’incident et déterminer s’il s’agit d’un véritable bug. 

Quant à l’erreur, on pourrait dire que c’est ce qui engendre le défaut. Dans le sens où c’est une action humaine mal réalisée, comme une erreur dans la conception d’une application, dans l’écriture du code, qui fait que le logiciel n’a finalement pas le résultat attendu. Il suffit alors de corriger cette erreur pour corriger le défaut ou alors modifier les spécifications pour que ce défaut soit finalement pris en compte en tant qu’évolution. 

En réalité, peu importe le niveau des bugs ou leur signification, le credo à garder en tête est qu’il faut les repérer et les corriger au plus vite, car cela peut avoir un impact direct sur votre business, que ce soit en termes d’image, financier ou juridique. À titre d’exemple, 86 % des Français renoncent à  un achat sur un site e-commerce à cause d’un bug, d’après notre enquête de 2020. 

D’où l’importance de bien tester son application ou son site avant de le mettre en ligne et de continuer à le faire régulièrement grâce à l’automatisation des tests fonctionnels !