Ceci est un guide pour rédiger des rapports de bug efficaces sur Discourse afin de maximiser les chances qu’ils soient corrigés.
Niveau utilisateur requis : N’importe qui peut signaler un bug
Rédiger un bon rapport de bug est essentiel pour aider l’équipe Discourse à résoudre les problèmes efficacement. Ce guide vous guidera à travers les étapes et les meilleures pratiques pour vous assurer que votre rapport de bug est clair, concis et exploitable.
Résumé
Dans cette documentation, nous aborderons :
- L’importance de fournir des étapes reproductibles et des détails précis
- Comment décrire le problème et le comportement attendu
- Les meilleures pratiques pour signaler des bugs sur différentes plateformes
- Le maintien d’un ton approprié dans votre rapport
- Les pièges courants et leurs solutions
Étapes pour rédiger un rapport de bug efficace
Priorité/Sévérité
Déterminez l’urgence de la correction du bug. Bien que tout le monde souhaite que ses problèmes soient résolus rapidement, réservez la priorité la plus élevée aux problèmes critiques qui ont un impact significatif sur le fonctionnement.
Plateforme
Spécifiez toujours l’environnement dans lequel le bug a été observé. Cela inclut :
- Type d’appareil (ordinateur de bureau, mobile, écran tactile, tablette)
- Système d’exploitation et sa version
- Navigateur web et sa version
Dans la mesure du possible, reproduisez le bug sur plusieurs plateformes pour en confirmer la présence.
Description
Soyez concis. Décrivez le problème simplement et sans détails inutiles. Séparez les différents problèmes s’ils peuvent être signalés individuellement. Un format de description clair comprend :
Résultat obtenu : Que se passe-t-il ?
Résultat attendu : Que aurait dû se passer ?
Évitez les suppositions sur ce que le lecteur sait déjà. Soyez explicite sur ce qui aurait dû être vu ou produit.
Étapes reproductibles
Assurez-vous que le bug peut être reproduit de manière constante. Rédigez des instructions étape par étape en commençant par l’écran d’accueil de Discourse. Si le bug apparaît de manière aléatoire, précisez sa fréquence (par exemple, 1 fois sur 10 tentatives). Pour les bugs liés à l’interface utilisateur (UI/UX), ajoutez des captures d’écran ou des vidéos pour plus de clarté.
Ton
Maintenez un ton respectueux et poli. Évitez d’utiliser le rapport de bug pour exprimer votre frustration. Tout langage ou comportement toxique peut entraîner un retard ou l’ignorance de votre rapport.
Modèle
Utilisez ce modèle pour créer rapidement un nouveau sujet de rapport de bug :
Priorité/Sévérité :
Plateforme :
Description :
Étapes reproductibles :
Meilleures pratiques
- Reproduire en mode sans échec : Avant de signaler, essayez de reproduire le problème en mode sans échec de Discourse si vous suspectez que des personnalisations pourraient en être la cause.
- Questionnez les hypothèses : Les rapports de bug découlent souvent de fausses hypothèses. Même dans votre rapport, questionnez et clarifiez toute hypothèse que vous pourriez avoir.
- Soyez détaillé : Pour les bugs difficiles à reproduire ou rares, fournissez autant de détails que possible. Incluez tout ce qui pourrait être lié, comme des messages d’erreur ou des fichiers journaux.
Problèmes courants et solutions
Problème : Impossible de reproduire le bug de manière constante.
Solution : Documentez l’environnement et les conditions dans lesquelles le bug apparaît. Notez tout modèle ou point commun.
Problème : Absence de réponse à un rapport de bug.
Solution : Assurez-vous que votre rapport est détaillé mais concis et rédigé avec un ton courtois.
FAQ
Q : Que faire si je n’ai pas le temps de rédiger un rapport détaillé ?
R : Il est toujours utile d’ouvrir un rapport avec les informations dont vous disposez. Indiquez que vous le mettrez à jour avec plus de détails plus tard.
Q : Où dois-je publier mon rapport de bug ?
R : Utilisez la catégorie appropriée : les rapports de bug doivent être publiés dans la catégorie Contribute > Bug.