Bts

Revision as of 10:55, 25 December 2009 by Claratte (Talk | contribs) (Created page with '[http://doc-fr.openflyers.com/index.php?title=Bts Voir cette page en français] =Introduction= We use a tool named "Bug Tracking System" [http://bts.openflyers.org/ Mantis] to......')

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Voir cette page en français

Introduction

We use a tool named "Bug Tracking System" Mantis to... track the bugs!

First, you need to be logged on in order to view and edit bug reports.

After an account creation, an email is automatically and instantaneously sent. If you do not receive this message, check that it has not been parked as a spam-mail or destroyed (in the trash directory) by an anti-spam tool that manages your mail box. At last, if you do not find the message, send us an email to ask for a manual account activation. Do not forget to specify your ident used at the account creation.

How-to report a bug

Before reporting a bug, spend some time doing these actions:

  • Check that there no report on the same bug.
  • In the report form, describe all the fields in order to avoid a bad report dispatching.
  • Choose the right category:
Title Description
Admin About configuration or administration
Booking About reservations
Flights Management About flight management
Accounting Management About accountancy
Documentation About anything dealing with the documentation
Update About the update tool
Translation About a bad translation in any langage
  • Choose the right OpenFlyers Product Version where you got the bug. The release number is written on the left-down part of the OpenFlyers login page.
    • 1.3.x
    • 2.0
    • 2.1beta
  • Summary:
 Write an explicit summary
  • Description:
  • If the bug is on an online release, write the name of the client space.
  • If the bug is on a local release, report the state of your database. You may proceed to database export in a state the bug is visible.
The description should be complete in order to give the capability to developers to identify the location of the trouble.
  • The "real" description of the trouble and how it appears (non display, warning, etc.).
  • Which actions do you perform to get the bug
  • Joining a screen snapshot is sometime more explicit thant a long description. Do not overuse!, we do not try to overload a report in order to delay the correcting actions but just to give explications to developers.
  • Use notes to add informations. Avoid emails exchange beside bug reports.
  • Once the bug is corrected, you will receive an advising email:
  • Please, feel free to confirm the right correction by stating the bug report to close.
  • If you see that the correction is not ok with your description (completely or partially), re-open the report by changing is state.
  • On the other hand, if you detect a new bug, so create a new report!
The the bug report closing should be performed by the reporting person.
If there is no action while a reasonable time, the developer or a manager will close it.

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