Rapporter un bug

Révision de 21 mars 2006 à 12:27 par Drpiquouze (discuter | contributions) (Rapporter un bug dans Mantis (pour les testeurs/rapporteurs))

Aller à : navigation, rechercher

Introduction

Nous utilisons comme outil de "traceur de bugs" (ou Bug Tracking System) Mantis.

Pour pouvoir éditer des informations, il faut d'abord vous identifier.

Lors de la création de votre compte, un mail vous est envoyé. Si vous ne le recevez pas, vérifiez qu'il n'a pas été mis de côté (voir supprimé) par un outil anti-spam attaché à votre messagerie.

Rapporter un bug dans Mantis (pour les testeurs/rapporteurs)

Avant de rapporter un bug, prenez le temps d'effectuer les actions suivantes :

  • Vérifier que le bug n'est pas déjà rapporté
  • Renseigner les items des le débuts pour éviter l'envoi dans une rubrique non adaptée
  • Choisissez la bonne catégorie :
Intitulé Rubrique
Admin si cela touche la partie configuration/administration
Cahier des resa si cela touche la partie "cahier de réservations"
Gestions des vols si cela touche la partie "saisie des vols"
Gestions des comptes si cela touche la partie financière
Documentation si cela concerne des précisions sur la documentation
Update si cela touche l'utilitaire de changement de version
Translation si cela touche les traductions (phrase dans une mauvaise langue ou manquante dans une langue)
  • Choisissez la bonne version d'OpenFlyers sur laquelle vous avez constaté le bug (en effet nous filtrons et pouvons donc passer à côté d'un bug répertorié sous une mauvaise version). Le numéro de la version d'OF que vous utilisez se trouve en haut à gauche de la page d'accueil d'OF.
    • 1.2.x
    • 2.0alpha
    • 2.0
  • Résumé :
 Rédiger un intitulé explicite comportant si possible le n° de référence du scénario correspondant (cf. script)
  • Dans la description

Si le bug est sur une version en ligne, indiquez sur quelle base vous avez testé. Si c'est une version en local, indiquez l'état dans laquelle est votre Base de données. Faire éventuellement une sauvegarde pour la figer dans un stade ou le bug est reproductible.

Le descriptif doit être complet pour que les développeurs sachent identifier l'endroit du problème.

  • La nature "réelle" (non affichage, warning, etc.) du problème et sa manifestation.
  • Communiquer TOUS les éléments minimaux pour commencer à réfléchir au pourquoi du problème, c'est à dire :
    • OS utilisé (Windows 98, Windows XP, Linux, UNIX, Jaguar, etc.)
    • Navigateur utilisé (Safari, Internet Explorer, Netscape Navigator, Firefox, etc.)
    • La version du navigateur.
  • Si vous utilisez une version d'OpenFlyers qui n'est pas hébergée par l'association OpenFlyers (si la version que vous utilisez est hébergée par l'association, alors son adresse internet est de la forme nomduclub.openflyers.org), merci de nous communiquer également les éléments suivants :
    • phpinfo() peut être utile pour pouvoir détecter un éventuel problème de configuration de votre serveur.
    • il serait souhaitable, pour épargner un temps précieux, de s'assurer avant de signaler un bug que tous les fichiers sont uploadés correctement (présents sur le serveur, modifications maîtrisées).

A noter que nous n'assurons pas le support pour les hébergeurs gratuits. En effet, ces derniers imposent souvent des limitations qui sont sans rapport avec les hébergeurs payants. Notre application fonctionne correctement sur un serveur Linux "standard" (avec quelques variantes possibles) mais avec des options qui peuvent parfois n'exister que sur des hébergeurs payants. La version 2.0 pourrait, par exemple, se révéler bien plus exigeante que la 1.2 au niveau des prérequis.

  • Joindre une copie d'écran est parfois plus explicite que de long discours. Ne pas en abuser, on ne cherche pas à documenter un bug pour le contourner mais à fournir des explications au développeur pour traitement.
  • En cours de traitement, utiliser les notes pour ajouter des informations, éviter les échéanges par email parallèle.

Si le bug est sur une version en ligne, indiquer sur quelle base vous avez testé. Si c'est une version en local indiquer l'état dans laquelle est votre Base de données. Faire éventuellement une sauvegarde pour la figer dans un stade où le bug est reproductible.

Le descriptif doit être complet pour que les développeurs sachent identifier l'endroit du problème.

Indiquer : votre système d'exploitation et le navigateur utilisé.

Joindre une copie d'écran est parfois plus explicite que de longs discours mais ne pas en abuser, on ne cherche pas à documenter un bug pour le contourner mais à fournir des explications au développeur pour traitement.

  • En cours de traitement, utiliser les notes pour ajouter des informations.
  • Lorsque le bug est résolu vous recevrez un email d'information. Vous devez fermer vos bugs. Si vous constatez que la solution ne correspond pas à votre description (totale ou parielle), relancez le sujet en le changeant d'état. Par contre si vous détectez une nouvelle anomalie rédigez un nouveau bug.
  • La fermeture du Bug doit être effectuée par celui qui l'a émis.
  • En l'absence d'action de votre part dans un temps raisonnable le développeur ou un administrateur le fermera.

Description des états et de l'avancement de la résolution

Etats

Intitulé de l'état Description Qui devrait mettre cet état
nouveau nouveau bug, c'est l'état initial le rédacteur du bug
commentaire le bug nécessite plus d'informations, le rédacteur du bug devrait y préter attention un gestionnaire ou un développeur
accepté le bug a été lu mais n'est ni confirmé ni assigné un gestionnaire ou le développeur dont dépend le bug
confirmé le bug est confirmé et reproductible un gestionnaire ou un développeur
assigné le bug est assigné à un développeur un gestionnaire ou un développeur qui le prend en charge
résolu le bug devrait être résolu, en attente de la confirmation de sa résolution par le rédacteur du bug le développeur qui a corrigé le bug
fermé le bug est fermé le rédacteur initial du bug ou un gestionnaire ayant confirmé le bug

Résolutions

Intitulé de la résolution Description
ouvert bug ouvert en attente
résolu bug résolu d'après le développeur responsable
réouvert bug considéré comme toujours existant après correction
impossible à reproduire le bug rapporté n'arrive pas à être reproduit
impossible à corriger il n'y a pas de possibilité de corriger le bug
doublon le bug a déjà fait l'objet d'un rapport dans Mantis
pas un bug Ce n'est pas considéré comme un bug
suspendu Le bug est mis de côté
ne sera pas résolu Le bug est reconnu mais ne sera pas résolu

Traitement des bugs dans Mantis (pour les développeurs et gestionnaires)

  • Lorsqu'un bug est résolu il faut faire attention à le marquer comme tel dans la version en cours de modif (=donc normalement la future version publiée)
  • La fermeture du Bug doit être effectuée par celui qui l'a reporté.
  • En l'absence d'action de sa part dans un temps raisonnable un gestionnaire le fermera.

Suivez vos bugs

Respect des standards du web

Nous avons à coeur de respecter les standards du web dont notamment le standard xhtml 1.0 strict.

Pour vérifier la validité d'une page, il existe plusieurs outils.

Voici comment utiliser celui fourni par le W3C :

  • Afficher votre page à l'aide d'un navigateur (firefox ou internet explorer)
  • sauver la page seule sur votre disque dur
  • Allez sur la page du validator du W3C
  • Uploader le fichier sauvé sur le disque dur
  • constatez le résultat