TravailleursDuWeb se BLACK OUT contre HADOPI

Quelques bonnes pratiques pour un debuggage efficace

Publié le 13 November 2008, par Babozor dans la catégorie Développement, Gestion de projet, Organisation, méthodo..., Outils

bug180.jpg

Chez Busineo, on est presque à la dernière ligne droite avant la mise en ligne: quelques semaines de développement et de debuggage et on sera prêt pour mettre en ligne la nouvelle version (en tout cas la partie fonctionnelle). Mais voilà un moment critique du développement d’une application web: le debuggage…

1. Trouver les outils adéquates
C’est la première partie de cette vaste tâche: trouver les outils adéquates à la structure de l’entreprise et aux gens qui vont l’utiliser. Vous pouvez toujours garder la méthode old-school (papier/crayon ou vieux fichier excell) mais par expérience deux écueils:
– transmission des informations: certaines informations risquent de ne pas être transmises aux bonnes personnes, avec pas les bonnes données et au final, certains bugs risquent de subsister
– oubli de certaines données: vous pensez avoir éradiquer tous les bugs, mais vous avez oublié ce bout de fichier excell qui traîne sur votre bureau avec pleins de bugs importants et poum la release est foirreuse…
Il existe énormément d’outils disponibles, soit des outils spécifiques, soit des outils que vous pouvez détourner pour faire du debuggage. Tout dépend ensuite de l’infrastructure et des personnes.
Pour ma part si vous souhaitez un bugtracker vraiment complet, je conseillerais Mantis, nous à Busineo on utilise Trac qui a un éditeur de tickets tout à fait correcte (ce sont deux applications WerbBased, il en existe beaucoup aussi en applications desktop).

2. Eduquer les testeurs
Après avoir installer les outils, voici la partie la plus dure: éduquer les testeurs.
Pour un debuggage efficace il faut tout d’abord que les testeurs utilisent les outils mis en place, cela veut dire pas de retour par voix orale ou par email, tout DOIT passer par l’outil, il faut les forcer à l’utiliser… par tous les moyens possibles, pour que cela devienne un réflexe.
Il faut aussi les éduquer à documenter les bugs, cela veut dire page, contexte, quelles données, etc…

3. Bug non reproduit = pas un bug
C’est une notion aussi qu’il faut essayer de faire rentrer dans la tête des testeurs, si eux ont vu un bug, c’est bien, mais si il est impossible à reproduire, pour vous il n’existe pas (puisque aucun moyen de le reproduire, aucun moyen d’en savoir la cause et donc de le corriger).
Donc si vous n’arrivez pas à le reproduire, refusez le systématiquement, à la charge du testeur de compléter sa fiche de bug.

4. Prioriser les bugs
Traitez les bugs les plus critiques en premier et ensuite par ordre d’importance… rien ne sert de s’acharner sur des bugs mineurs qui ne gênent pas fondamentalement l’expérience utilisateur (cela peut être fait après quand vous aurez plus de temps)

5. Savoir laisser passer certains bugs
C’est paradoxal mais vrai, certaines fois debugger une fonctionnalité vous amènera plus d’emmerdes et de bugs que de le laisser… c’est difficile mais parfois laisser un bug connu et identifié (mais pas gênant pour l’utilisateur) peut être une bonne solution.

6. En tuer le plus posible, le plus vite possible…
Tous les développeurs le savent, debugger c’est chiant! Rien de plus insupportable que ça, c’est beaucoup plus rigolo de développer de nouvelles fonctionnalités, donc essayez de les tuer le plus vite possible, pour pouvoir passer à autre chose.

Et vous, ça ressemble à quoi votre debugagge?



Laissez un commentaire