Un bogue ou un défaut logiciel existe lorsque le comportement réel s’écarte du comportement attendu. C’est alors que les clients sont mécontents et que le moral de l’équipe de développement est atteint.
Si le comportement attendu n’est pas clair, un écart par rapport à ce qui est intuitivement attendu soulève la question : est-ce un bogue ou une fonctionnalité ? Dans tous les cas, du point de vue du client, les bogues ne sont pas souhaitables. Les équipes de développement axées sur le client font de leur mieux pour identifier et corriger les bogues.
Il existe deux manières complémentaires de visualiser les bogues logiciels. Une façon de les voir implique la métaphore des insectes nuisibles qui peuvent être éliminés à l’aide de pesticides. Les bugs logiciels sont les insectes et les tests logiciels sont le pesticide. La deuxième façon consiste à les considérer comme une opportunité d’apprentissage qui nécessite les bons processus d’apprentissage.
Défauts, erreurs et pannes
Mais qu’est-ce qu’un bug exactement ? Qu’est-ce qui peut faire dévier un produit logiciel du comportement attendu ? En termes de code de programmation, il peut y avoir des pannes, des erreurs et des échecs. Un défaut dans le code peut entraîner une erreur. Une erreur peut entraîner un échec.
Une autre métaphore pourrait nous aider à clarifier ces concepts. Nous nous réveillons le matin et avons des douleurs ou des vertiges. Considérez ces symptômes comme des échecs. Nous avons décidé d’aller chez le médecin. Le médecin mesure notre pression qui s’avère très faible. Considérez cela comme une erreur puisque notre pression ne devrait pas être si basse ! Ensuite, on fait une prise de sang qui montre un taux de cholestérol élevé. Le taux de cholestérol élevé est une autre erreur comme tout écart par rapport aux niveaux acceptables. Le médecin analyse tous les échecs et les erreurs. Elle essaie de découvrir la faute (ou les fautes) qui ont entraîné les erreurs qui ont conduit aux échecs.
Les erreurs peuvent s’additionner et entraîner des échecs plus importants (plus de douleur). Les erreurs peuvent être sans rapport les unes avec les autres, certaines provoquant des échecs tandis que d’autres n’en provoquent aucun. Les erreurs peuvent également s’annuler les unes les autres, entraînant peu ou pas d’échecs (peu ou pas de douleur). Ils peuvent être dus au même défaut, à des défauts différents ou à l’interaction entre défauts.
Voici un exemple de méthode simple qui accepte des tableaux de nombres et compte le nombre de zéros.
Méthode numZero a un défaut dans l’expression d’initialisation de la variable i. A cause de ce défaut, numZero ne prend pas en compte le premier élément du tableau d’entrée. C’est une erreur. Par conséquent, si le premier élément est nul, alors numZero échouera dans le calcul. Cependant, si le premier élément est différent de zéro, numZero n’échouera pas. Par exemple, numZero ([1, 9, 0, 7]) s’évalue correctement à 1 tant que numZero ([0, 1, 2, 6]) entraîne un échec car il est incorrectement évalué à zéro.
Il y a une tendance dans l’industrie du logiciel à utiliser le terme bogue ou défaut de manière informelle pour désigner l’un des trois : Défauts, erreurs et échecs.
Types de bogues
Pour trouver des bugs, nous devons tester. Par conséquent, les types de bogues sont conformes aux types de tests que nous effectuons pour les détecter. Il existe des bogues fonctionnels où la fonctionnalité est cassée. Il existe également des bogues non fonctionnels comme des bogues de sécurité, des bogues de fiabilité, des bogues de disponibilité, des bogues d’utilisabilité et des bogues de performance. Bogues de validation d’entrée, bogues de chemin heureux, bogues de test négatifs, bogues de régression, bogues de test de fumée et bogues détectés via des tests manuels ou via des tests automatisés. La liste des types de bogues est longue mais surtout, les tests ne peuvent pas prouver qu’il n’y a pas de bogues. Cela peut aider à acquérir la confiance que nous avons trouvé la plupart d’entre eux ou les plus importants. Soyez conscient cependant d’éviter le piège consistant à chercher constamment à atteindre zéro bogue après chaque activité de test. Cela vaut-il toujours l’effort et les coûts?
Les bogues doivent être détectés tôt
Un bogue peut être créé à de nombreuses étapes du cycle de vie du développement logiciel (SDLC). Lors de l’analyse des besoins, de la conception architecturale, du développement ou du déploiement. Plus tôt nous détectons et corrigeons un bogue, mieux c’est. En effet, le coût de la correction d’un bogue augmente considérablement à mesure que nous passons des exigences à la conception, au développement, puis aux tests d’assurance qualité. Comme le dit un proverbe anglais : Un point dans le temps en sauve neuf.
Pour détecter les bogues, les tests à tous les niveaux sont essentiels. Au niveau de l’unité, au niveau de l’intégration, au niveau de l’API, au niveau du système ou à un niveau acceptable.
Un groupe de logiciels a utilisé des testeurs tout au long du SDLC. Les bogues détectés lors de l’analyse des exigences ont été documentés et résolus avec une priorité élevée.
Un autre groupe a formé des analystes commerciaux et des propriétaires de produits pour qu’ils aient un état d’esprit de test. Ils rechercheraient des cas positifs et négatifs et des cas limites problématiques. Ayant trouvé de tels problèmes, ils aviseraient directement les testeurs d’incorporer des scénarios spécifiques lors de la conception de leur cas de test.
Un autre groupe employait des Product Owners qui étaient de bons testeurs exploratoires. Des personnes qui avaient les connaissances nécessaires pour explorer et la capacité de critiquer les exigences de manière constructive. Des personnes qui avaient également des connaissances dans le domaine des affaires et une volonté de se développer et de se concentrer sur cela. Les propriétaires de produits avec une telle expérience attraperaient souvent des bogues tôt. Ils prendraient également les mesures nécessaires pour éviter des exigences complexes. Ils ont généré des exigences claires, sans ambiguïté, complètes et testables.
Le paradoxe des pesticides
Suivant la métaphore insecte-pesticide, avec le temps, les insectes en biologie deviendront immunisés contre les pesticides et nous devrons utiliser de nouveaux pesticides pour les tuer. De même, les bogues logiciels dans notre code seront immunisés contre nos tests et nous aurons besoin de nouveaux tests pour les trouver et les corriger.
Les tests se concentrent sur des zones spécifiques du code et, avec le temps, ils trouveront moins de bogues. En effet, le code testé sera éventuellement amélioré et peu (ou pas) de défauts seront détectés. Si nous voulons que nos tests détectent toujours des bogues importants, nos cas de test doivent évoluer à mesure que notre code évolue.
Systèmes de suivi des défauts
Un système de suivi des défauts est un outil permettant de documenter les problèmes et les correctifs. Des informations telles que la priorité et la gravité des défauts, les étapes de reproduction, les solutions de contournement possibles, ainsi que l’émetteur et le cessionnaire, sont quelques-uns des détails inclus.
Une équipe considérait la documentation des défauts comme une reprise et un gaspillage. Ils ont corrigé les bugs dès qu’ils ont été découverts. Les tests unitaires ont été écrits pour reproduire les défauts et le code a été corrigé pour que les tests unitaires réussissent. Les tests et le correctif ont ensuite été enregistrés et le travail se poursuivait normalement. Les testeurs collaboraient avec les développeurs dès qu’un problème était découvert. Si un développeur pouvait fournir un correctif immédiatement, le bogue n’était pas documenté. Si aucun développeur n’était immédiatement disponible ou si le correctif nécessitait une prise de décision difficile, le bogue était documenté.
Une autre équipe créerait une liste de bogues dans un document Google partagé entre les testeurs, les développeurs et les propriétaires de produits. Il s’agissait de bogues trouvés lors des tests de fonctionnalités et avant la publication de la fonctionnalité. Au moins tous les bugs importants ont été corrigés avant la sortie. Si la décision était de publier des fonctionnalités candidates avec des bogues de faible priorité, ils les documenteraient dans un système de suivi des défauts. Ils ont toujours documenté les défauts détectés après la publication des fonctionnalités.
Il y avait un groupe qui considérait les systèmes de suivi des défauts comme une base de données de connaissances. Tous les bogues ont été signalés au système, qu’ils aient été trouvés avant ou après la publication des fonctionnalités. Ils cherchaient des modèles dans les bogues. Ils posaient des questions comme y a-t-il des bugs interdépendants ? Pourquoi certains bogues qui sont corrigés reviennent-ils sans cesse ? Pourquoi certains bugs spécifiques sont-ils sporadiques ? L’analyse des causes profondes a été menée dans le but de trouver des réponses et d’apprendre comment éviter que des problèmes similaires ne se reproduisent.
Détecter les bugs est une chose, les corriger en est une autre
Bien que la prévention, la détection et la correction des bogues tôt dans le SDLC soient clairement une bonne pratique, la correction des bogues peut être difficile. Si les coûts de réparation sont supérieurs aux coûts de non-réparation, une solution de contournement pourrait peut-être rendre les clients heureux (si disponible). C’est peut-être à ce moment que les systèmes de suivi des bogues pourraient être très utiles puisque tous les problèmes connus qui doivent être résolus peuvent être clairement documentés et communiqués à toutes les parties prenantes. Les bogues importants qui nécessitent une collaboration entre les équipes, qui peuvent également nécessiter des décisions difficiles entre les équipes et peuvent prendre du temps à corriger, doivent être documentés. Peut-être avons-nous trouvé un bogue important, mais il y en a actuellement d’autres qui doivent être corrigés. Nous devrions corriger les plus importants en premier tout en gardant les moins importants filtrés par priorité.
Bogues introduits artificiellement en tant que processus d’apprentissage
Des bogues peuvent également être introduits artificiellement dans le système pour vérifier si les processus existants sont suffisamment bons pour les détecter. Il s’agit d’une politique qui a été populaire dans un certain nombre de groupes de logiciels.
Un groupe a introduit des bogues d’interface utilisateur pour vérifier si leurs exécutions d’automatisation des tests nocturnes les intercepteraient. Un autre groupe avait une session régulière de formation sur les bogues pour les développeurs. Des bogues ont été introduits par l’équipe DevOps et des conseils ont été donnés aux développeurs afin de les trouver et de les corriger.
Un groupe a introduit des bogues au niveau du microservice pour vérifier le comportement du microservice. Ils étaient également intéressés de voir comment ces bogues soigneusement conçus se propageraient à travers les microservices.
Un certain nombre de groupes incitaient à des fautes pour s’assurer que leurs systèmes étaient tolérants. Ils allumaient et éteignaient les systèmes et exécutaient délibérément des logiciels qui provoquaient des pannes. Ils ont appris à quel point leurs systèmes étaient tolérants, quels types de défaillances peuvent survenir, comment améliorer ces problèmes et comment réagir à un certain nombre de circonstances imprévues.
Emballer
Les bogues logiciels existent sous une forme ou une autre dans presque tous les produits logiciels. Leur présence rend tout le monde mécontent, y compris les clients et les équipes de développement de logiciels. Peut-être que l’une des conditions préalables à l’épanouissement d’un ingénieur logiciel est de maintenir un équilibre entre les fautes, les erreurs et les échecs dans le code. Puisqu’ils sont inextricablement liés à notre travail, nous devons savoir clairement comment les prévenir autant que possible, comment les repérer lorsqu’ils sont introduits et comment les réparer et les gérer en toutes circonstances.