Pourquoi soigner son ticket ?
Pour gagner du temps
Lorsque que l’on résout un bug, il est très courant de mettre plus de temps à le reproduire qu’à le fixer. Pour cela, il est primordial d’avoir le maximum d’informations pour pouvoir le reproduire, si possible systématiquement. C’est donc au moment de rédiger son ticket, ou rapport de bug, qu’il est indispensable de prendre le temps d’être exhaustif pour gagner (beaucoup) de temps par la suite.
L’objectif est simple : faire en sorte que le ticket soit reproduit et donc fixé le plus rapidement possible.
Parce que vous ne le rédigez pas pour vous
Un ticket est rédigé pour être compris. Il n’est pas seulement là pour rappeler à votre prestataire de corriger cette anomalie. Ce ticket va passer entre de nombreuses mains : même si vous avez expliqué le bug au chef de projet, le ticket sera attribué au référent fonctionnel, qui lui-même va qualifier le ticket avant de le transmettre au(x) développeur(s)… Si vous voulez éviter la perte d’information, mieux vaut être complet dès le début.
Le cycle de vie d’un ticket
Nos conseils pour bien décrire un bug
Créer 1 ticket par problème et par plateforme
Créez autant de ticket qu’il y a de bug, modification, retour. Il vaut mieux 10 tickets détaillés – dont vous pourrez fermer certains et laisser les autres ouverts – qu’un ticket contenant 10 retours différents et dont certains seront noyés dans la masse.
Divisez également les tickets selon les plateformes : iOS, Android, site web, back-office…
Vous avez un doute sur la division des tickets : est-ce le même bug ou un bug différent ? Créez 2 tickets, et indiquez dans les deux que vous pensez qu’ils sont liés. Par exemple : il me semble qu’il s’agit du même problème sur la page des notifications – ticket 1423
Détaillez votre ticket
Donner un maximum de détails dans votre rapport d’anomalie.
Nom explicite
Un nom simple, qui permet de comprendre rapidement le problème, et distinct, qui différencie facilement des autres tickets.
Description détaillée de l’anomalie
- Expliquer précisément comment est survenu le bug
- Expliquez ce que vous observez et donnez le comportement attendu : donnez la liste des étapes qui amènent à reproduire le bug. Pensez à être attentif à votre parcours utilisateur lorsqu’un bug survient.
- Vous devrez bannir définitivement la phrase « Ça ne marche pas » et privilégier une description précise.
Précisez l’environnement sur lequel le bug a été identifié
- Version d’OS : Android 10, iOS 13…
- Navigateur et version :
- Chrome,
- Chrome for Android
- Firefox,
- Edge,
- Safari
- iOS Safari,
- Samsung explorer…
- Modèle du téléphone,
- Résolution d’écran…
Vous trouverez toutes ces informations dans les paramètres de votre téléphone ou de votre navigateur. Cela peut paraitre fastidieux, mais une fois que l’on connait les caractéristiques de ses terminaux, ça ne prend pas plus de temps, mais ça en fait gagner beaucoup au moment de la résolution du bug !
Ajoutez des captures d’écran si besoin
Une image vaut mieux qu’un long discours ; n’hésitez pas à ajouter une capture d’écran ou une capture vidéo. Cela permet de comprendre des comportements parfois difficiles à décrire ou d’obtenir des informations pour lesquelles nous n’aurions pas posé la question.
Identifier la bonne priorité ou criticité
Selon les outils de suivis de tickets, il faudra donner un niveau de gravité du bug rencontré. L’objectif est de classer les tickets par ordre d’importance afin de se concentrer en premier lieu sur les problèmes les plus gênants.
Voici un tableau indicatif pour identifier la priorité du bug que vous remontez :
Autres systèmes de classements :
- Bloquant / Critique / Majeur / Mineur / Cosmétique
- Critique / Urgent / Normal / Non urgent
Sélectionnez le bon type de ticket
Les types suivants sont généralement disponibles dans les outils de suivi :
Assignez à la bonne personne
Assignez le ticket à votre référent projet : chef de projet, référent fonctionnel, référent technique… Cela permettra à cette personne de suivre l’ensemble de vos tickets, de les qualifier si besoin et de les transmettre aux développeurs pour correction.
Quels outils de ticketing utiliser ?
Chez Mobizel, nous utilisons Redmine, qui nous convient parfaitement ! Si vous souhaitez en tester d’autres, voici une liste non exhautive :
- Jira
- Taiga
- Mantis
- Bugzilla
- …