Il était une fois un bug, et puis un autre, et ça continue encore et encore, c’est que le début, d’accord, d’accord. Pas une semaine ne passe sans que vous ne découvriez un nouveau bug sur votre site web ou votre application mobile. Et honnêtement, vous n’êtes pas loin de vous en arracher les cheveux. Vous ne savez plus quoi faire pour les gérer. Qu’on se le dise : un site ou une application mobile sans anomalies, ça n’existe pas. C’est un mythe. Ou en tout cas, une rareté. Et bien qu’il soit utopique d’éradiquer totalement les bugs sur les plateformes web et mobiles, il existe actuellement de nouvelles techniques pour en minimiser le nombre. Mais commençons déjà par comprendre d’où ils viennent en premier lieu.
Un bouton qui ne marche pas, un mauvais affichage, une erreur 404, un problème de connexion : les anomalies sur les sites web ou les applications mobiles peuvent provenir d’une multitude de raisons. À commencer par le facteur humain. Car à partir du moment où les plateformes web ou mobiles sont développées par des humains, les erreurs peuvent arriver. Mais voici quelques causes courantes qui peuvent entraîner des bugs :
Les régressions ont lieu dès lors qu’un changement de code a un impact sur le code existant. Par exemple, quand une nouvelle fonctionnalité est implémentée, si celle-ci perturbe le comportement des fonctionnalités précédemment existantes, alors il y a régression, car un bug a été introduit.
Mais quelles sont les raisons d’une régression ? Cela peut provenir du fait que le code est mal architecturé, qu’il y a une mauvaise gestion des erreurs, un mauvais système de gestion des versions, une mauvaise relecture avant le merge, de mauvaise pratiques de développements (ou pas de pratique du tout), ou encore que les équipes travaillent de façon trop indépendante de sorte que les modules sur lesquels elles travaillent peuvent avoir un impact les uns sur les autres.
Tester, c’est douter ? Certains vous diraient que oui, mais ils seraient bien prétentieux. Car si le logiciel ou l’application n’a pas été testé de manière approfondie, dès le début de son cycle de développement jusqu’à sa mise en production (et même ensuite d’ailleurs), alors il existe une très, très, très (il n’y a jamais trop de très) grande probabilité que des bugs se retrouvent en production. Et doit-on vraiment rappeler encore une fois l’impact que peut avoir un bug sur un utilisateur final ?
Attention : tester, c’est bien (même très, très, très bien), mais faut-il encore bien tester. Et cela demande notamment de choisir les bons tests à exécuter et de les faire aussi au bon endroit. Il s’agit d’ailleurs de l’un des grands principes du test : les tests montrent la présence de défauts, mais ils n’en démontrent pas l’absence. C’est pour cela qu’il est important de bien tester et au bon endroit, afin de repérer les bugs les plus critiques et ce, de manière efficace. Le test est l’indicateur de mesure indispensable de la qualité applicative.
Le manque de communication est-il la cause de tous les maux du monde ? C’est fort possible et une chose est sûre, cela provoque de nombreux bugs. Parce qu’on le sait tous, le manque de communication entre des équipes suscite des malentendus, des suppositions, mais aussi des incompréhensions. Et dans le cadre du développement web ou mobile, tout l’enjeu de la communication se passe dès la phase des spécifications.
Les spécifications servent à décrire la vision des personnes qui les créent. Par exemple, le métier a un besoin et le Product Owner va rédiger les spécifications. Ensuite, les développeurs vont développer les spécifications, puis les testeurs vont tester les développements des spécifications. Et s’il existe des lacunes dans la communication entre ces différentes personnes, que tout le monde ne communique pas efficacement pour développer le produit et que chaque strate est cloisonnée, cela crée un effet tunnel qui peut mener jusqu’à des anomalies critiques et c’est l’utilisateur final qui ramasse les pots cassés.
Nous avions déjà évoqué quelques tips pour éviter et limiter les bugs dans un précédent article, en misant notamment à fond sur la qualité, mais il existe également des techniques de développement qui permettent de les prévenir.
Le Test-Driven Development, ou développement piloté par les tests en français, est une méthode de développement qui consiste à écrire les tests avant d’écrire le code. Mais encore ? En gros, on écrit d’abord un test, on l'exécute, puis on valide que le test est en échec, puisque la fonctionnalité n’a pas encore été implémentée. Ensuite, on développe la fonctionnalité et on rejoue le test jusqu’à ce qu’il soit en succès, etc.
Pourquoi cette méthode marche contre les bugs ? Parce que si des tests sont créés avant même que la fonctionnalité ou le produit ne soient développés, la probabilité que cette fonctionnalité ou ce produit atteigne ses utilisateurs finaux sans avoir été testé est considérablement réduite. Qui plus est, effectuer des tests régulièrement permet de détecter plus tôt les bugs et donc de les corriger avant la mise en production.
Attention, cependant, le TDD reste très ciblé test unitaire et cela demande un travail en amont de définition des tests, ce qui est parfois compliqué à mettre en place dans un projet urgent.
Différente du TDD, la méthode du Behavior-Driven Development, ou programmation pilotée par le comportement en français, encourage quant à elle la communication et la collaboration entre tous les intervenants du projet (développeurs, ingénieux qualités, commerciaux, testeurs, etc). Cela permet de s’assurer que toute l’équipe ait une compréhension commune de la façon dont l’application doit se comporter. Et cela se traduit notamment par des tests écrits dans un langage compréhensible par tous, avant le début du développement de la fonctionnalité ou du produit. Grâce à cette méthode de BDD, il est possible de relever des bugs assez tôt dans la conception et donc de les prévenir.
Commençons par le commencement. L’approche CI, aka Continuous integration, aka l’Intégration continue, est une méthode qui consiste à intégrer le nouveau code écrit par les développeurs au code source d’une application le plus tôt et le plus fréquemment possible (au moins une fois par jour) tout au long du cycle de développement. Des tests automatisés sont effectués à chaque modification du code source (d’où le continuous testing), pour vérifier que cela n’a pas produit de régression et que les nouvelles fonctionnalités sont implémentées correctement.
Cela garantit une surveillance continue, tout au long du cycle de vie des applications et permet notamment de s’assurer que toutes les régressions sont détectées dès leur introduction. Cela permet d’économiser beaucoup de temps et d’efforts qui seraient autrement consacrés à la recherche des changements qui ont provoqué la régression, par exemple.
Cela demande par contre un investissement très important dans l’automatisation de tous les types de tests (unitaires, intégration, système, bout en bout…).
>> Attention, ces techniques de développement ne fonctionnent pas forcément pour tout le monde. Cela dépend de la structure, de la dynamique de votre équipe, du contexte projet, de votre stratégie de tests, etc. Avec toutes ces techniques de prévention, vous n'êtes cependant pas à l'abri de laisser passer un bug (le zéro bug n'existe pas), mais vous ne devriez pas laisser passer les plus critiques qui auront le plus d'impact.
En bref, pour mieux gérer les bugs, il faut avant tout pouvoir les détecter et cela nécessite donc simplement de mettre en place des démarches basées sur les tests. Cependant, comme nous le disions plus haut, il ne suffit pas de tester, il faut encore bien tester et cela passe par une documentation vivante par les tests, et notamment par les tests automatisés. Mais cela fera l’objet d’un prochain article ;)