KjerrUn modèle de rapport de bug
prêt à copier.
Un bon modèle de rapport de bug mène un développeur de la lecture à la reproduction en une seule fois : ce qui s’est passé, ce qui était attendu, les étapes, et où. Copiez le modèle ci-dessous dans un document, un formulaire ou votre outil de tickets, ou reprenez les mêmes champs sur un tableau qui accepte aussi les fichiers.
Le modèle de rapport de bug
Sept questions. Rendez obligatoires le titre et les étapes ; laissez le reste facultatif.
Titre
Ce qui ne marche pas, et où. Une ligne.
Exemple : L’export CSV télécharge un fichier vide
Que s’est-il passé ?
Ce que vous avez vu, en une phrase ou deux.
Qu’attendiez-vous ?
Ce qui aurait dû se passer à la place.
Étapes pour reproduire
1.
2.
3.
À quelle fréquence ?
À chaque fois, parfois, ou une seule fois.
Où ?
Navigateur ou version de l’application, système d’exploitation, compte ou espace de travail.
Quelque chose à montrer ?
Une capture d’écran, un enregistrement d’écran, un journal, un fichier HAR.
Un exemple de rapport de bug
Le même modèle, rempli. Le produit et les chiffres sont inventés.
Titre
L’export CSV télécharge un fichier vide
Que s’est-il passé ?
J’ai cliqué sur Exporter dans la page Rapports. Un fichier s’est téléchargé,
mais il ne contient que la ligne d’en-tête.
Qu’attendiez-vous ?
Les 214 lignes affichées dans le tableau à l’écran.
Étapes pour reproduire
1. Ouvrir Rapports et choisir les 30 derniers jours.
2. Filtrer sur l’offre « Scale ».
3. Cliquer sur Exporter, puis sur CSV.
À quelle fréquence ?
À chaque fois avec le filtre. Sans le filtre, l’export fonctionne.
Où ?
Chrome 141 sous macOS 15. Espace de travail : northwind.
Quelque chose à montrer ?
export.csv (le fichier vide), rapports.har
À quoi sert chaque champ
- Titre. Ce qui ne marche pas et où : on retrouve le rapport plus tard, et les doublons se rencontrent.
- Que s’est-il passé ? Le symptôme, avec les mots de la personne, avant toute interprétation.
- Qu’attendiez-vous ? La moitié des rapports tiennent à un malentendu, et cette ligne montre de quelle moitié il s’agit.
- Étapes pour reproduire. La partie qu’un développeur ne peut pas deviner. Numérotées, une action par ligne.
- À quelle fréquence ? « À chaque fois » fait penser à la logique ; « parfois », à un problème de timing ou de données.
- Où ? Le navigateur, la version et le compte resserrent la recherche mieux que n’importe quelle description.
- Quelque chose à montrer ? Un enregistrement ou un journal remplace trois paragraphes.
Du modèle au formulaire de rapport de bug
Un formulaire de rapport de bug doit demander moins que le modèle. Chaque champ obligatoire fait perdre des rapports, et un rapport perdu coûte plus cher qu’un détail manquant.
- N’exigez que le titre et les étapes pour reproduire.
- Mettez un exemple dans le texte indicatif de chaque champ : on voit le niveau de détail attendu.
- Affichez les rapports proches avant l’envoi du formulaire, pour qu’on puisse ajouter un vote plutôt qu’un doublon.
- Laissez joindre des fichiers en les déposant sur le formulaire.
- Dites ce qui se passe ensuite : où le rapport apparaîtra et comment la réponse arrivera.
Que joindre à un rapport de bug
Les preuves abrègent la conversation. Voici les fichiers qu’il vaut la peine de demander, et ce que chacun permet de trancher.
- Une capture d’écran, pour tout ce qui se voit.
- Un enregistrement d’écran en MP4, quand les étapes sont difficiles à décrire.
- Un fichier HAR, quand une page ne se charge pas, n’enregistre pas ou n’exporte pas.
- Un journal de la console ou du serveur, en TXT ou en LOG.
- L’e-mail lui-même, en EML, pour les problèmes de réception et de mise en forme.
- Le fichier CSV, XLSX ou JSON qui n’a pas voulu s’importer, ou le fichier exporté qui contient des erreurs.
Recueillir les rapports de bug sur un tableau Kjerr
Un tableau Kjerr peut poser les questions du modèle et conserver les preuves. Derrière, l’outil de gestion des retours clients montre à l’équipe ce qui est nouveau.
- Le formulaire se modifie : ajoutez « Étapes pour reproduire », « Résultat attendu » et « Où » comme champs à vous, jusqu’à 10 champs en tout, chacun obligatoire ou facultatif, avec son propre texte indicatif.
- Jusqu’à 5 fichiers de 10 Mo sur un rapport ou un commentaire : images, PDF, EML, TXT, LOG, CSV, JSON, HAR, ZIP, DOCX, XLSX, PPTX et MP4.
- Les rapports proches s’affichent pendant la saisie du titre, chacun avec son bouton de vote.
- Pour un tableau destiné à votre équipe QA, réservez-le aux membres et limitez la connexion au domaine e-mail de votre entreprise : le même réglage que pour une boîte à idées.
- Quand le statut passe à Shipped, l’auteur du rapport et tous ceux qui ont voté reçoivent un e-mail.
- Ce n’est pas un outil de tickets : ni responsables attitrés, ni niveaux de gravité, ni sprints.
Des questions, des réponses franches.
Qu’est-ce qu’un modèle de rapport de bug ?
Un modèle de rapport de bug est une série fixe de questions qui obtient les mêmes faits de chaque rapport : ce qui s’est passé, ce qui était attendu, les étapes pour le reproduire et l’endroit où cela s’est produit. Le développeur passe de la lecture à la reproduction sans aller-retour de questions.
Que doit contenir un rapport de bug (bug report) ?
Un titre d’une ligne, ce qui s’est passé, ce qui était attendu, des étapes numérotées pour reproduire, la fréquence du problème, l’environnement, et des preuves comme une capture d’écran ou un journal. Si deux éléments seulement peuvent être obligatoires, prenez le titre et les étapes.
Quelle différence entre un rapport de bug et une demande de fonctionnalité ?
Un rapport de bug dit que le produit ne fait pas ce qu’il promet. Une demande de fonctionnalité réclame ce qu’il n’a jamais promis. Les questions à poser ne sont pas les mêmes ; pour la seconde, prenez le modèle de demande de fonctionnalité.
Comment écrire de bonnes étapes pour reproduire ?
Partez d’un état que tout le monde peut atteindre, écrivez une action par ligne et donnez les valeurs exactes que vous avez saisies ou choisies. Arrêtez-vous à l’étape où le problème apparaît. Si une étape est parfois nécessaire et parfois non, dites-le.
Qu’est-ce qu’un fichier HAR, et faut-il en joindre un ?
Un fichier HAR est un enregistrement des requêtes qu’une page web a effectuées, que l’on exporte depuis les outils de développement du navigateur. Joignez-en un quand une page ne se charge pas, n’enregistre pas ou n’exporte pas. Vérifiez-le d’abord : il peut contenir des cookies de session et des données personnelles.
Kjerr peut-il remplacer un outil de suivi des bugs ?
Non. Kjerr recueille les rapports, élimine les doublons et prévient leurs auteurs quand le statut change. Il n’a ni responsables attitrés, ni niveaux de gravité, ni sprints, et ne se synchronise ni avec Jira ni avec Linear. Les équipes s’en servent comme porte d’entrée, et gardent leur outil de tickets derrière.
À lire aussi
Donnez une réponse à vos utilisateurs.
Kjerr est gratuit pendant l’accès anticipé : toutes les fonctionnalités, sans carte bancaire. Quand les offres payantes arriveront, elles seront facturées par espace de travail, jamais par siège administrateur.