AppReviewX Se connecter

Comment rédiger un rapport de bug en tant que testeur

Les cinq éléments dont chaque rapport a besoin, avec un exemple annoté et les erreurs courantes à éviter.

mis à jour ·2 min de lecture

Dans ce guide

Un bon rapport de bug permet au développeur de voir le problème sans avoir à te poser de questions. En tant que testeur, tu écris à partir de ce que tu as vu, pas à partir de ce que fait le code. Cinq éléments rendent un rapport exploitable.

Les cinq éléments de chaque rapport

  1. Un titre court. Une ligne qui dit ce qui ne va pas et où. « Le bouton Enregistrer ne fait rien sur l'écran de profil ».
  2. Étapes pour reproduire. Numérotées, en partant d'un point connu. « Ouvre l'app, touche Profil, change le nom, touche Enregistrer. »
  3. Ce que tu attendais. « Le nom se met à jour et je reviens à la liste. »
  4. Ce qui s'est passé à la place. « Rien. Aucun message, l'écran reste. »
  5. Où tu l'as vu. Modèle du téléphone, version du système, version ou build de l'app si tu la connais. Une capture d'écran ou un enregistrement d'écran si cela aide.

Indique aussi la fréquence : à chaque fois, ou seulement parfois.

Exemple annoté

Exemple, pas un vrai rapport.

Mauvais : « Profil cassé. Merci de corriger. » - Aucun lieu, aucune étape, aucune attente. Le développeur doit deviner et te poser des questions.

Bon :

Le bouton Enregistrer ne fait rien sur l'écran de profil 1. Ouvre l'app et connecte-toi. 2. Touche Profil, change le nom, touche Enregistrer. Attendu : le nom est mis à jour, retour à la liste. Obtenu : rien ne se passe, aucun message. Se produit à chaque fois. Téléphone : [modèle], système [version]. Capture d'écran jointe.

  • Le titre nomme le problème et l'endroit.
  • Les étapes peuvent être suivies par un inconnu.
  • Ce qui était attendu et ce qui s'est passé sont séparés.
  • L'appareil est indiqué.

Erreurs courantes

  • Plusieurs problèmes dans un même rapport. Écris un rapport par problème.
  • Deviner la cause. « La base de données est cassée » est une supposition. Décris ce que tu as vu.
  • Étapes manquantes. Si tu sautes la partie qui te paraît évidente, le développeur ne reproduira peut-être pas le problème.
  • Mots vagues. « Lent », « bizarre », « cassé » ne veulent pas dire la même chose pour tout le monde. Dis ce qui s'est passé.
  • Ton. Décris le problème, pas la personne. Voir étiquette du testeur.

Avant d'envoyer

Relis-le comme un inconnu. Pourrais-tu reproduire le problème à partir du seul texte ? Sinon, ajoute l'étape manquante.

Sur AppReviewX, ton retour va en privé au propriétaire de l'app. 1 retour écrit = 1 crédit.

Étapes suivantes

Tester une app et gagner des crédits. Un modèle plus long figure dans l'article sur le modèle de rapport de bug.

Associés :