Voilà LA question qu'on oublie de se poser et qui est pourtant l'essence même du test !
Pourquoi il y a des bugs, des anomalies ?
Il y a une multitude de raisons qui expliquent la présence de bugs dans les applications, les sites web, ou dans l'utilisation des objets connectés.
Tant que le métier de développeur existera, il y aura des bugs. Sachant que les logiciels se complexifient chaque jour, le "bug free" est une notion erronée : le test est une activité aussi fondamentale que le développement, les deux activités étant tout à fait indissociables.
Mais la question demeure : pourquoi y-a-t-il des bugs ? Comment en arrive-t-on à avoir des bugs dans le process de développement logiciel ? Voici 10 raisons, dans le désordre, qui apportent une partie de la réponse.
Il y a des bugs parce que les logiciels sont développés par des hommes et des femmes et l'erreur est humaine, tout simplement. Parce que les Hommes sont imparfaits par essence, ils sont enclins à faire des erreurs. Il serait donc absurde d'imaginer que les logiciels puissent être développés parfaitement sans aucun défaut ! Enfin, parce que nous n'avons pas encore trouvé mieux que l'intelligence humaine pour développer, il faut simplement accepter que l'erreur fasse partie de l'équation.
Les bugs, c’est-à-dire les défauts qui se glissent dans le produit/logiciel, s'expliquent également par le malentendu, le manque de communication ou l'incompréhension durant les phases de développement. L'échec de la communication peut se produire à plusieurs niveaux : phase de récupération des spécifications (specs), interprétation des specs et/ou phase de documentation, implémentation des specs…
Imaginez un projet où les spécifications sont vagues ou incomplètes. Les programmeurs se retrouvent dans des situations qui favorisent les incompréhensions, les menant potentiellement à faire les mauvais choix et donc des erreurs.
Soyons honnête : la plupart du temps, les logiciels sont développés dans des temps impartis insensés, avec des ressources souvent limitées et des deadlines projet irréalisables. Il est donc habituel que des compromis soient faits par exemple sur les spécifications, le design ou les fonctionnalités à développer, afin de respecter les délais de livraison. Trop souvent, les équipes de développement n'ont pas assez de temps pour programmer, intégrer et tester leur code avant de le passer aux équipes de test. Des modifications de design de dernière minute exigent parfois des évolutions du code, ce qui peut indiscutablement faire naître des bugs.
La complexité des systèmes logiciels est devenue inhérente à tout projet. Parfois, le logiciel est si compliqué qu'il nécessite un niveau de R&D et de brainstorming conséquent pour atteindre le niveau de fiabilité et de qualité requis. Seulement, l'impatience et l'envie de lancer le produit au plus vite pousse à la précipitation et conduit à des erreurs. Un mauvais usage des technologies (composants, produits, techniques), la tentation d'utiliser les moyens les plus faciles et rapides pour développer la solution, un manque de connaissance sur la faisabilité technique avant même de concevoir l’architecture, etc. : toutes ces situations, et d'autres, mènent à des erreurs. Hélas ce n’est pas l’intelligence humaine qui fait défaut mais le manque de temps dédié à la réflexion nécessaire pour construire des projets complexes.
Parfois, des erreurs se glissent dans le code simplement parce que le code est mal fait. De mauvaises pratiques de codage telles que la mauvaise gestion des erreurs et exceptions, des oublis dans la validation/revue du code (datatypes, type de champs, conditions aux limites, mémoire saturée, etc.) peuvent introduire des bugs. Par ailleurs, les développeurs travaillent parfois avec des outils de mauvaise qualité, des compilateurs, debuggers, outils de profilage ou de validation de code défectueux, etc. rendant quasiment inévitable l’apparition de bugs, et leur réparation encore plus difficile !
Si, en tant que testeur, vous n'arrêtez pas de rencontrer des bugs de régression qui apparaissent à intervalles réguliers, c'est qu'il est temps de vérifier le système de gestion de versions (VCS, version control system). Maintenir des versions différentes en simultané permet de conserver une trace de tout le travail effectué mais aussi les changements apportés au code source (codebase). L’absence totale de VSC pour sauvegarder les changements fréquents du codebase est un très bon moyen pour obtenir un grand nombre de bugs de régression.
Même si un VCS (ex. Visual SourceSafe) est mis en place, il est possible que des erreurs se glissent dans les versions finales (builds) du logiciel, notamment lorsque les développeurs ne parviennent pas à lier les versions les plus récentes de chaque module (partie du code) à la nouvelle build en cours.
Très souvent au cours des développements, les équipes ont recours à de nombreux outils tiers, qui sont également des logiciels développés par des hommes, et donc peuvent contenir des bugs. Ces logiciels peuvent être des outils d’aide à la programmation (ex. bibliothèques de classes, de liens dynamiques, compilateurs, éditeurs HTML, debuggers, etc.) ou des plug-ins/add-ons prêts à l’emploi utilisés pour gagner du temps (comme un plugin e-commerce, une API map navigation, un service tiers de support technique 24/7, etc.). Un bug présent dans ces outils peut logiquement provoquer à son tour des défaillances dans le logiciel en cours de développement.
Aucun testeur ne voudrait l'admettre et pourtant, les tests de mauvaise qualité ont bien lieu au sein des organisations. Il peut y avoir des lacunes dans le processus de test. Le manque de sérieux pour les tests, l'insuffisance de compétences métiers, le peu d’importance accordée à l’activité de test, etc. toutes ces situations sont de véritables menaces au métier de test logiciel. Laissez à votre équipe un temps d'introspection et elle vous fera sans doute part de lacunes ! Vous pourriez argumenter que des tests médiocres n'introduisent pas de bugs, en effet. Mais des tests de mauvaise qualité laissent des bugs persistants dans le logiciel. De plus, dans cette époque de méthode agile, bâcler les tests unitaires (ex. en méthode TDD, Test Driven Development) revient à fragiliser le code et donc à augmenter le risque de bugs.
Les modifications apportées aux spécifications, à l’infrastructure, aux outils, à la plateforme peuvent être délicates surtout si elles sont faites au dernier moment avant la mise en production. Des manipulations comme la migration de la base de données, le fait de rendre votre produit/logiciel compatible avec le maximum d’OS et de devices, etc. peuvent être complexes et entraîner de sérieux problèmes dans l’application si elles sont réalisées « à la va-vite » suite à une soudaine évolution des specs. Ce genre d’évolutions tardives peut conduire à des modifications du code de dernière minute qui risquent de faire naître des bugs.
En sachant que dans cet article nous avons parlé des causes possibles de bugs dans les logiciels, vous avez bien sûr remarqué une erreur dans l’article ! Nous vous avions promis 10 raisons, mais il n’y en a que 9 ! C’est fait exprès. Pourquoi ne pas nous faire part, en commentaire de cet article, de vos propres explications afin de compléter la liste (10e raison, puis 11e, 12e…). Tous vos retours d’expérience sur les bugs logiciels nous intéressent ; n’hésitez pas à les partager avec nous. Merci !