Les 7 familles de bugs

Ca-y-est, c’est la panique ! Le client est bloqué et menace de rompre le contrat si les problèmes ne sont pas résolus avant la fin de la semaine. Le directeur informe alors le responsable qui convoque le chef de projet (ou de produit) pour qu’il réquisitionne immédiatement ses développeurs afin de corriger les bugs au plus vite.

Déjà-vu ? Sans blague ! Et oui, encore une fois, les développeurs vont se mettre à l’œuvre, modifier quelques lignes de code qui seront livrées au client pour le débloquer. Et au final, que retiendra-t-on de cet évènement ? Qu’il restait un bug dans le code.

Alors c’est ça la fin de l’histoire ? Les départements informatiques, les équipes projets et les R&D grouillent de gens plus expérimentés, plus respectés, et mieux payés que les développeurs, mais au final, le bug et sa résolution resteraient le fait du développeur ?
Eh bien non ! C’est faux. Ils ne sont pas les seuls à faire des bugs. En voici pour preuve les 7 familles dans lesquelles il est possible de classer la quasi-totalité des bugs :

1. Le bug du débutant : il s’agit le plus souvent d’une mauvaise gestion des cas limites dans l’implémentation des algorithmes : non vérification de la valeur des paramètres d’entrée d’une fonction, dépassements de capacité d’une pile ou d’un tableau, tentative d’accès à une ressource non disponible. Ces bugs doivent être éliminés par les tests unitaires. A noter que ces bugs peuvent également apparaître lorsque le développeur est optimiste ou trop pressé.

2. Le bug du collègue : les développeurs s’appuient parfois sur le travail d’un collègue pour ne pas avoir à redévelopper une fonction, une classe ou un composant. Si le code du collègue contient des bugs, ceux-ci seront immanquablement intégrés dans le logiciel final. Depuis quelques années, la démocratisation des frameworks Open-Source a poussé la réutilisation de code jusqu’à un niveau jamais atteint. Dans ce cas, il s’agira plutôt d’un confrère que d’un collègue.

3. Le bug du testeur : le testeur doit mettre en place un environnement reflétant les futures conditions d’utilisation du logiciel. Il doit faire en sorte que la couverture fonctionnelle qu’il adresse soit complète, que les jeux de données ou les scénarii qu’il utilise soient représentatifs et permettent de couvrir tous les chemins possibles. Il doit tester dans les conditions réelles d’utilisation : versions de SGBD, serveur d’application, OS, middleware….

4. Le bug du release manager : le release manager est responsable de la production des livrables à partir du code source. Il doit veiller à utiliser la bonne version des sources et les bonnes options de compilation. Ces opérations, peuvent être jugées triviales, mais elles sont en réalité particulièrement délicates lorsqu’il s’agit de produire des correctifs de type Hot-fix, ou lorsque le même code source est destiné à produire plusieurs versions des livrables (multi OS, 32bits/64bits).

5. Le bug de l’architecte : ses symptômes peuvent être très variées : difficultés lors de l’intégration dans l’écosystème cible, incapacité à supporter la montée en charge, impossibilité d’intégrer des évolutions fonctionnelles pourtant « raisonnables ». De plus, il apparaît souvent tard dans le cycle de vie du logiciel, parfois bien après la mise en production. C’est pourquoi il est souvent difficile à diagnostiquer. Pourtant, ses causes sont souvent les mêmes : non respect des principes de base (KISS, SOLID, etc.), choix de composants tiers non adaptés, définition d’architectures non scalables ou difficilement testables, etc.

6. Le bug du chef de projet : l’incapacité à collecter une expression du besoin complète, l’incapacité à chiffrer correctement la charge de développement, l’incapacité à négocier un planning raisonnable avec le client, l’incapacité à maîtriser les évolutions du périmètre alors que les développements sont déjà en cours sont les bugs typiques du chef de projet.

7. Le bug du directeur : certains directeurs refuseront probablement d’admettre qu’eux aussi font des bugs, mais soyons réalistes ! Le refus d’approuver l’achat d’un composant à 1 000 € qui permettrait pourtant d’éviter un développement de 50 jours à faible valeur ajoutée ou complètement en marge du projet et qui ne pourrait de toute façon pas être testé correctement est clairement une source de bugs. Idem pour le refus d’investir dans des plates-formes matérielles ou logicielles qui reflètent les conditions réelles d’utilisation du logiciel.

Bref, pour résumer, les débutants font des bugs de débutant, les développeurs expérimentés ne font plus de bugs, et tous les autres bugs sont produits par des intervenants non développeurs ! Et pourquoi pas ?

Eh bien non ? Ca aussi c’est faux ! Et disons-nous le une bonne fois pour toutes, du débutant au directeur, tout le monde fait des bugs ! Et ce n’est pas parce qu’un développeur peut bricoler en quelques heures une parade à une anomalie bloquante que c’est lui qui était à l’origine du bug.