Guide de rapport de bogues sur IssueZilla
Dernière mise à jour le 06 Août 2001 (traduction et adaptation française le 27 Mars 2002)
Les parties françaises en italique sont la traduction des champs que vous rencontrerez dans le formulaire.
Pourquoi devez-vous lire ceci
Simplement parce que le plus efficacement vous reportez un bogue, le plus rapidement un ingénieur le corrigera. Ce guide est un tutoriel général pour l'écriture efficace d'un rapport de bogues, par un utilisateur novice dans l'utilisation d'IssueZilla. Toutes les parties ne vous seront pas nécessairement utilies pour le bogue que vous reportez.
Comment écrire un rapport de bogue efficace
Un bogue bien reporté est un bug qui sera corrigé rapidement. Un bon bogue doit avoir deux qualités :
Reproductible. Si un ingénieur ne le reproduit pas et n'arrive pas à prouver qu'il existe, c'est ingénieur va sûrement l'estampiller comme 'INVALID/INVALIDE' ou WORKSFORME/NON REPRODUCTIBLE et passer à un autre bogue. Chaque détail que vous pouvez donner est une aide précieuse
Spécifique. Le plus rapidement un ingénieur peut isoler le bogue comme un problème spécifique, le plus rapidement également il pourra le régler. (Si un programmeur ou un testeur doit déchiffrer un bogue, il passera plus de temps à maudire la personne qui a reporté le bogue qu'à essayer de le fixer ou de le tester.)
Disons que l'application que vous testez est une feuille de calcul reçue comme document attaché
Mauvais : « Calc plante quand j'essaye d'ouvrir un document. Je pense qu'il contient un diagramme. Je suis sous Windows. Je pense que c'est un problème grave et que vous devriez le corriger maintenant. D'autre part vos icônes sont vraiment laides. Personne n'utilisera votre logiciel si vous conservez ces horribles icônes. Oh, ma grand-mère a un problème avec le traitement de texte. Rien ne marche non plus. Bonne chance ».
Bon : « Mon ordinateur se plante à chaque fois que j'essaie
d'ouvrir la feuille de calcul attachée en utilisant la version 10.13.00
sous Win NT 4.0 (Service Pack 5). J'ai également essayé sous Linux (RedHat
6.2) et j'ai reproduit le problème toujours en utilisant la version 10.13.00
pour Linux.
Lorsque j'ai supprimé le diagramme du document, j'ai pu ouvrir le document
sans problème. »
Comment créer un rapport de bogue efficace dans IssueZilla
Pour reporter un bogue, vous devez être inscrit comme utilisateur OpenOffice.org. Pour s'enregistrer, c'est très simple : cliquez sur le lien « Join/S’incrire » dans la barre de navigation et suivez les instructions. Cela ne prend que quelques minutes. Si vous êtes déjà enregistré, cliquez sur le lien « My Issues/Mes Bogues » sur la barre de navigation à gauche ou sur le lien « Bugs ans Issues » de la barre de navigation. La page suivante est une page explicative sur IssueZilla et indique également des liens utiles comme le lien d'interrogation de la base de données (Query/Requête)
Rendez-vous sur la page de recherche IssueZilla Query Page pour déterminer si le défaut que vous avez constaté est un bogue connu et a déjà été reporté (si votre bogue est reporté pour la 37e fois, vous allez plutôt embêter l'ingénieur et un ingénieur embêté est un ingénieur qui résoud moins de bogues !)
Assurez-vous que vous avez pu reproduire votre bogue en utilisant une version récente. N'hésitez pas à faire appel à la mailing liste (http://fr.openoffice.org) pour que ce bogue soit reproduit par d'autres et sur d'autres systèmes d'exploitation. (Les ingénieurs sont souvent plus intéressés par des problèmes affectant le code base sur lequel ils sont en train de travailler, plutôt que ceux ayant trait à un code source déjà corrigé des centaines de fois et dont les bogues sont obsolètes).
Si vous découvrez un nouveau bogue se rapportant à une version récente, entrez-le sur IssueZilla :
A partir de la page principale de IssueZilla, choisissez « Enter a new issue/entrer un nouveau bogue »
Sélectionnez le component/composant (ou module) dans
lequel vous avez trouvé le bogue
IssueZilla demande que vous indiquiez un module dans lequel vous avez rencontré
le bogue (si cette liste ne vous dit rien, cliquez sur le lien Component, qui vous conduira à une page descriptive
des différents éléments, afin que vous puissiez faire le meilleur choix)
Entrez votre adresse e-mail, votre mot de passe et appuyez sur le bouton « Login » (Si vous n'avez pas encore de mot de passe, laissez la case « mot de passe » vide et appuyez sur le bouton « e-mail me a password/envoyez moi un mot de passe ». Vous recevrez alors, rapidement, un mail avec votre mot de passe.
Maintenant, remplissez le formulaire. Voici ce qu'il signifie :
Où avez-vous trouvé le bogue ?
Reporter/Rédacteur : Qui
écrit ce rapport de bogue ?
C'est vous ! Pour entrer un bogue, vous devez être inscrit et «logué».
Component/Composant : Dans
quel module / composant / produit avez-vous trouvé ce bogue ?
Vous venez juste de remplir cela à la page précédente
Subcomponent/Sous-composant :
Dans quel partie du composant principal avez-vous trouvé ce bogue
?
Vous avez généralement le choix entre UI (User Interface/Interface Utilisateur)
et code. Code est utilisé uniquement si vous connaissez l'emplacement du
bogue dans le code source, sinon choississez UI.
Version/Version : Dans quelle version
du produit avez-vous trouvé le bogue ?
Donnez le numéro de version, si possible.
Plateform/ Plateforme : Sur quel
type de plateforme avez-vous rencontré ce bogue ? (ex SUN, PC)
Si vous savez que ce bogue est reproductible sur toutes les plateformes,
choisissez « All/Toutes ». Sinon sélectionnez la plateforme sur laquelle
vous avez trouvé le bogue, ou « Other/Autre » si la plateforme n'est
pas listée.
OS/Système d'exploitation : Sur
quel système d'exploitation avez vous trouvé le bogue ? (ex Linux, Windows
NT)
Si vous savez que ce bogue est reproductible sur tous les systèmes d'exploitation,
choisissez « All/Tous ». Sinon, sélectionnez le système sur lequel
vous avez trouvé le bogue, ou « Other/Autre » si le système n'est
pas listé.
Quelle importance a ce bogue ?
Resolution Priority/Priorité de résolution
: Quelle urgence de correction demande ce type de bogue ?
Le choix par défaut est « 3 ». 1 est le choix le plus urgent, 5 le moins
urgent.
Issue Type/Type de bogue : Est-ce
une defect/anomalie, enhancement/amélioration, feature-request/fonction
demandée, task/tâche, patch/patch.
Par défaut le choix dans la liste est « defect/anomalie ». (Pour déterminer
le type de bogue le plus approprié, cliquez le lien « Issue Type/Type de bogues » pour avoir accès à une
description complète des choix proposés ainsi qu'à la procédure de vote).
Qui va suivre ce bogue ?
Assigned to/Assigné à : Quel développeur
va être responsable de la correction de ce bogue ?
IssueZilla va assigner automatiquement ce bogue à un ingénieur par défaut.
Ce cadre de texte existe cependant pour vous permettre d'assigner directement
la tâche à un ingénieur différent (pour voir la liste des ingénieurs chargés
par défaut des différents éléments, cliquez sur le lien envoyant vers la
liste des éléments « Component ».
CC/Copie : Qui d'autre va recevoir
un e-mail concernant les changements apportés à ce bogue ?
Listez ici l'adresse complète des personnes qui doivent recevoir un e-mail
concernant les changements apportés à ce bogue. Vous pouvez entrer autant
d'adresses que vous le désirez, ces adresses doivent être séparées par une
virgule, et sans espaces entre les adresses.
Que pouvez-vous dire d'autre à l'ingénieur au sujet de ce bogue ?
URL : Sur quelle URL avez-vous découvert
ce bogue ?
Si vous avez rencontré ce bogue à une adresse particulière, merci de la (ou
les) indiquer.
Summary/Sommaire : Comment pourriez-vous
décrire ce bogue en 60 (ou moins) caractères ?
Un bon sommaire doit permettre d'identifier de manière unique et rapide un
rapport de bogue. Autrement, les ingénieurs ne seront pas interpellés par
votre rapport et leur attention ne sera pas retenue lorsqu'ils liront leur
10 pages de rapport de bogues.
Un sommaire du style « Echec à l'installation sur une RedHat 7.0, kernel 2.2.14 » est utile. « Echec du logiciel » ou « Echec à l'installation » représentent des mauvaise exemples.
Description/Description : Que pouvez-vous
dire d'autre à l'ingénieur au sujet de ce bogue
Essayez de détailler le plus possible le diagnostique du problème. Une description
pas à pas, précise, est la meilleur façon de pratiquer.
Pour les crash, si vous pouvez apporter des indications additionnelles, cela peut aider :
Win 32 : Si vous recevez une erreur de Dr Watson, veuillez noter le type de crash et le module dans lequel l'application crash.
Unix : Merci d'indiquer une trace de la pile
Target Milestone/Date butoire. Considérez-le comme une date limite ; la cible est « non déterminé » ou « prochaine version » -- pour la plupart des bogues, utilisez « non déterminé ».
Vous y êtes ! Après avoir vérifié vos entrées et possibles erreurs, pressez le bouton « Commit/Envoyer », et votre rapport de bogue va maintenant se retrouver dans la base de données d'IssueZilla.
N'hésitez pas à accompagner votre description d'un exemple ou d'un document attaché.
(Ce Guide a été écrit originellement pour Mozilla par Eli Godberg. Merci à Claudius Gayle, Peter Mock, Chris Pratt, Louis Surarez-Potts, Tom Schutter, et Chris Yeh pour leur contribution à ce document).