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 :

  1. 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

  2. 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 :

  1. A partir de la page principale de IssueZilla, choisissez « Enter a new issue/entrer un nouveau bogue »

  2. 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)

  3. 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 :

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).