QA/BugTriage/fr

From The Document Foundation Wiki
< QA‎ | BugTriage
Jump to: navigation, search

Ce document fournit des informations sur le processus de tri des bugs de LibreOffice. Le tri est le nom donné pour confirmer, donner une priorité et organiser les rapports de bugs et c'est un bon endroit pour commencer à contribuer et/ou si l'on a des capacités de programmation limitées afin d'aider LibreOffice à devenir un meilleur produit pour chacun. Le tri est un aspect extrèmement important du développement qui bénéficie tant aux utilisateurs qu'aux développeurs.

Des détails sont également disponibles sur Comment reporter des bugs LibreOffice.

Où trouver d'autres membres de l'équipe QA

Il y a plusieurs endroits où vous pouvez entrer en contact avec des membres de l'équipe QA dont plusieurs d'entre eux seront à même de répondre à vos questions et sont très actifs eux-même dans le tri des bugs.

1. Mailing Listes

  • libreoffice-qa@lists.freedesktop.org
  • libreoffice@lists.freedesktop.org
  • qa@fr.libreoffice.org (liste en français)

2. IRC

  • libreoffice-qa
  • libreoffice-dev
  • libreoffice-fr (canal en français)

3. Membres de l'équipe QA
Voici une liste des membres de l'équipe QA (soyez libre d'ajouter votre nom si vous avez l'intention de contribuer à la QA). Si l'utilisateur vous a donné la permission de les contacter directement, soyez libre de le faire, vous les trouverez très souvent sur le canal IRC.

Étapes pour trier un bug

Cette section liste les étapes nécessaires afin de réaliser un tri correct. Ce guide tente d'être précis, les liens de certaines sections fourniron des informations complémentaires relatives à une étape particulière. Le processus de tri peut être essentiellement séparé en trois parties, la première étant la "préparation", la seconde la "reproduction", la troisième la "définition de priorité".

Résumé des étapes

  1. Trouver des bugs à trier
  2. Rechercher les doublons de ce bug
  3. Vérifier les informations fournies dans le rapport de bug
  4. Essayer de reproduire le bug
  5. Définir le statut du bug
  6. Définir la priorité du bug
  7. Notifier les développeurs -- Nécessaire uniquement dans des cas très spécifiques si le bug semble être un bloqueur ou critique.

Détails des étapes

Préparation

En général, vous suivrez toujours ces étapes dans la préparation du tri des bugs Rappelez-vous que vous ne pouvez travailler sur des bugs que lorsque vous êtes connecté sur (veuillez créer un compte si vous n'en avez pas déjà un).

Étape 1. Trouver un bug à trier

a) Recherche FreeDesktop
Naviguez jusq'au système de traqueur de bugs de LibreOffice disponible sur bugs.documentfoundation.org. Après vous être connecté browse ouvrez les issues par composant ou faites une rechercher personnalisée sur les bugs qui :

a) sont remplis dans le produit LibreOffice

b) ont un statut UNCONFIRMED ou REOPENED

c) ajoutez tout autre critère sur lequel vous souhaitez faire une requête

Une fois que vous en êtes là, recherchez les bugs que vous souhaitez trier. La recherche personnalisée de bugs peut être réalisée en utilisant Advanced Search form ou en saisissant les termes de la recherche dans le champ de recherche rapide (Bugzilla Quick Search help). Vous pouvez également suivre ces liens directs de recherche, cliquer sur le lien afficher la page de résultat Bugzilla

b) Google Documents Bug Groups
Nous expérimentons un document partagé qui regroupe les bugs. N'hésitez pas à le consulter et vous attribuer une feuille (il y a quelque chose comme 1-50 bugs par feuille, tous organisés par "composants" (ie. writer, feuille de calcul, etc...))

Step 2. Rechercher les doublons

Les doublons sont des bugs marqués RESOLVED DUPLICATE qui sont très similaire ou identique mais rapportés par différents utilisateurs. Ces bugs sont automatiquement comptés par Bugzilla et disponibles sur la page Such bugs are automatically counted by Bugzilla and available at page des bugs les plus fréquemment rapportés. Lors du tri, veuillez vérifier cette liste et faire une recherche dans les bugs bugzilla pour s'il n'y a pas de doublons du bug que vous avez, mais n'y passez pas cependant trop de temps. Au fur et à mesure que vous verrez plus de bugs, vous serez à même de vous rappeler de ceux que vous avez déjà vus et pourrez facilement fermer le plus récent des deux. En général, minimiser le nombre de doublons entrés dans Bugzilla économisera du temps pour l'équipe de QA.

Si vous trouvez un doublon, sautez à l'étape #5

Step 3. Vérifier les informations

Vérifier les informations est critique pour le développement. Vous devez vérifier les informations suivantes :

  1. Un résumé clair et significatif
  2. Une description claire du problème
  3. Des étapes pour reproduire le problème -- si ce n'est pas déjà claire dans le sommaire ou la description
  4. Attachements -- dans la plupart des cas, un attachement est nécessaire à la reproduction du problème, si un attachement n'est pas fourni, cela peut entraver la correction du bug.

Si toutes les informations ne sont pas fournies, allez à l'étape #5

Step 4. Essayer de reproduire

Si le bug a "passé" les étapes de préparation, il est temps d'essayer de le reproduire.
Faites just cela, suivez les étapes nécessaires et essayez de reproduire le bug, c'est simple ! Lorsque vous le reproduisez, gardez ceci en tête :

  1. Est-ce que le rapporteur du bug a laissé suffisemment d'informations pour reproduire le bug ou avez-vous dû ajouter des étapes supplémentaires ? Si des étapes supplémentaires sont nécessaires, ajoutez un commentaire pour les décrire.
  2. Est-ce que votre reproduction a amené au même résultat, à quelque chose de similaire mais pas identique Did your reproduction result in the same thing, something similar but not identical, ou est-ce que tout a fonctionné parfaitement ?

Step 5. Définir le statut

Cette section est la dernière étape "nécessaire" pour un tri de bug correct et ne peut être réalisée qu'après les étapes #1 - #4 (ou #3 si #4 n'est pas applicable).

Le STATUT du bug est dépendant des résultats des étapes ci-dessus. Vous trouverez ci-dessous une description courte de quand utiliser chaque statut.

  1. NEW - bug confirmé, toutes les informations nécessaires sont présentes
  2. NEEDINFO - Toutes les informations nécessaires à la réplication du bug ne sont pas présentes dans le rapport. Veuillez demander à la personne concernée les informations particulières dans le commentaire.
  3. RESOLVED - Cette catégorie vient avec plusieurs options, si vous ne pouvez pas reproduire le bug RESOLVED WORKSFORME est le STATUT approprié, voir ICI pour plus d'informations.
  4. INVALID - Il y a de nombreuses raisons pour lesquelles un bug peut être déterminé comme non valide mais cela réclame en général un avis d'autres membres de l'équipe QA. Si vous rencontrez un bug que vous pensez être non valide, le mieux est d'obtenir un second avis sur le canal IRC QA ou d'envoyer un mail à la mailing liste expliquant pourquoi vous pensez que ce bug n'est pas valide.
  5. UNCONFIRMED - C'est le statut donné à tout nouveau bug qui n'a pas encore été trié. Notez que ce bug peut aussi avoir le statut NEEDINFO.

CHAQUE fois que vous faites une modification sur le bug, vous devez ajouter un commentaire expliquant poliment pourquoi vous avez fait cette modification
Les diagrammes ci-dessous sont des exemples de comment penser visuellement la définition du Statut, n'hésitez pas à éditer et mettre en ligne votre propre version si vous le souhaitez.
Example 1 PDF
Example 1 Draw

Step 6. Définir la priorité

Actuellement, nous mettons en avant uniquement les bugs critiques en mettant en CC les développeurs, en ajoutant une entrée spécial au Whiteboard, des mots-clé et en mettant à jour le MAB. Voir ci-dessous pour plus d'informations.

La définition de priorité est actuellement un sacré bazar, mais comme trieurs, nous devons toujours activement essayer d'améliorer les choses. Mettre une priorité à un bug est relativement subjectif mais le trieur doit toujours essayer d'être cohérent avec la façon d'attribuer une priorité. Les membres de l'équipe QA doivent avoir une idée claire de ce qui constitue chaque priorité et ensuite essayer de s'en tenir à cette méthodologie. Il est également très important de laisser un commentaire après avoir défini la priorité afin que le rapporteur (ainsi que les développeurs et les autres utilisateurs) prenne connaissance du processus de pensée que vous avez utilisé pour arriver à ce statut de priorité.

Les diagrammes ci-dessous sont des examples de représentation visuelle de la définition des statuts, n'hésitez pas à les éditer ou à mettre en ligne votre propre version si vous le souhaitez.
Example 1 JPG
Example 1 Draw

Étapes supplémentaires utiles (facultatives)

Mots-clé

Utilisez le mot-clé regression si la version mineure précédente fonctionnait correctement. Veuillez ne pas noter comme des régressions des bugs plus anciens.

Les régressions récentes sont généralement très ennuyeuses pour les utilisateurs affectés et plus facile à réparer. Elles sont donc traitées avec une priorité plus importante par les développeurs. D'un autre côté, si une régression met des mois ou des années à être rapportée, c'est que cela doit être une fonctionnalité moins utilisée et que les utilisateurs y sont habitués et a donc moins d'importance.

Statuts du Whiteboard

Whiteboard statut sont une liste de statuts facultatifs qui ont été déterminés comme étant utiles à affiner les requêtes. Certains de ces statuts ont une attention spéciale de la part d'un groupe de développeurs. Nous pouvons les diviser par objet :

Un des statuts intéressant du Whiteboard est needsDevEval. Un EasyHack qui probablement ne prendra pas très longtemps à être corrigé par un nouveau développeur et/ou par un développeur qui n'a pas de grandes capacités de développement. En tant que membre de la QA nous ne devons PAS marqué un de ces bugs comme EasyHack parce que cela requiert plusieurs étapes supplémentaires (incluant de trouver un développeur mentor & faire des backtrace). Si vous pensez qu'un bug peut être qualifié comme easyhack, marquez-le commme PROPOSEDASYHACK et envoyez ensuite un mail à la mailing liste des développeurs ayant pour sujet POSSIBLE EASY HACK FDO#.

Vérifier des informations supplémentaires

En tant que trieur, nous devons vérifier les informations qui sont rapportées originellement par le rapporteur. Les As a triager we should try to check the information that was originally reported by the bug reporter. Les choses à vérifier sont :

  • Product
  • Version
  • Platform

Ajouter un développeur à la liste de CC

Cette étape doit être réalisée uniquement si vous êtes sure que c'est suffisemment important de mettre un développeur en CC. Si vous pensez qu'un bug est suffisemment sérieux pour qu'il doive appeler une attention particulière mais peut être pas assez pour être ajouté au MAB, alors vous devez demander des avis supplémentaires. Veuillez utiliser cette fonction avec attention, nous ne voulons pas que nos développeurs soient inondés de demandes concernant des bugs mineurs. Pour ajouter la personne, ajoutez simplement son nom à la liste des CC et ajoutez un commentaire dans le bug expliquant la raison pour laquelle vous avez ajouté la personne en CC. Le nom correct correspondant figure sur cette liste d'experts.

Ajouter un membre QA à la liste des CC

Ceci n'est pratiquement pas utilisé, si vous pensez que c'est utile de vous ajouter vous-même ou un autre membre de la liste QA, n'hésitez pas à le faire. À nouveau, assurez-vous d'ajouter un commentaire si vous ajoutez quelqu'un d'autre, celui-ci s'irriter sinon de ne pas savoir de quoi il retourne.

Bugs les plus ennuyants (MAB)

Les bugs les plus critiques doivent être soulignés comme Most Annoying Bugs (MABs). Veuillez y réfléchir à deux fois avant d'ajouter le bug, nous souhaitons garder la liste à un niveau raisonnable.

Hard Hacks

Si un bug apparaît comme étant spécifiquement difficile, affecte un grand nombre d'utilisateurs et doit être considéré comme un MAB, le bug est alors candidat pour un hard hack. La liste peut en être trouvée ici :

Hard Hack Wiki