Assurance Qualité (QA)

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

Qu'est-ce que la QA?

QA est l'abréviation de Quality Assurance ou Assurance Qualité en français. La QA permet d'améliorer et de tester les versions les plus récentes de LibreOffice afin d'obtenir un logiciel de bonne facture pour les utilisateurs.

Comment participer

Vous pouvez participer de plusieurs façons :

  • Chasse aux bogues lors de sessions IRC
  • Tests manuels
  • Tests automatiques avec Unit Tests
  • Tests supplémentaires
  • Essayer simplement de confirmer des rapports de bug LibreOffice UNCONFIRMED. C'est vraiment très très simple :
    • Cherchez dans la liste un bogue portant sur une fonctionnalité que vous maîtrisez
    • Essayez de reproduire le problème en suivant les instructions pas à pas
    • Laissez un commentaire concernant votre résultat dans le rapport de bogue (Vous devez vous enregistrer si vous n'avez pas de compte)
C'est tout, "l'équipe" poursuivra le travail nécessaire à la suite.

Versions

  • Si vous recherchez la version actuelle de LibreOffice, suivez ce lien.
  • La Pre-Release est la version de test principale "officielle".
  • Si vous êtes intéressé par les développements en cours, vérifiez nos nightly builds - fournies par des contributeurs et non approuvées par la QA, ces versions ne sont absolument pas destinées à un travail en production. Caveat emptor.
  • Comment installer et utiliser plusieurs versions en parallèle.
  • Sous Windows, Florian Reisinger a développé un outil pour gérer les différentes versions installées en parallèle : téléchargement, installation, fichier d'aide, raccourci sur le bureau, modification du fichier bootstrap.ini (pour utiliser un profil différent pour les tests)... tout a été pensé pour automatiser toutes ces tâches. Server Install GUI est disponible ici.

Processus général de QA

La QA se fait réellement à toutes les étapes, du développement à la phase finale de délivrance de la version. Cette section fournit un guide à partir duquel vous .pouvez suivre les différentes actions de test.

Vous pouvez aussi vous reporter à l'exemple de notre Test marathon de la version 4.0.

Rapport de bug

Si vous trouvez quelque chose qui a l'air d'un dysfonctionnement, nous disposons d'un guide complet pour vous aider à comprendre comment créer un rapport de bug efficace dans LibreOffice.

Triage des bugs

Vous pouvez aider à trier et confirmer les bugs qui ont été reportés sur l'outil de suivi de bugs de LibreOffice. Pour commencer, créez vous un compte sur l'outil de suivi de bugs et suivez les instructions sur la page de wiki.

Rapports envoyés par le BSA/FR

Lorsqu'un dysfonctionnement est rapporté à travers l'assistant de rapport de bug disponible sur le site francophone, un rapport sous forme de mail est envoyé à la liste d'assurance qualité francophone. L'équipe va vérifier ce rapport et saisir sa confirmation si nécessaire sur BugZilla, ou commenter une issue existante. Si vous souhaitez participer, suivez les instructions données sur cette page

VOTER pour les fonctionnalités

Vous pouvez prendre part au triage et à la confirmation des bugs qui ont été reportés sur l'outil de suivi de bugs de LibreOffice. Pour commencer, créez un compte sur l'outil de suivi de bugs et suivez les instructions sur la page wiki.

Process de QA pour les versions candidates

Critère des versions

Les critères des versions définissent comment nous traitons une version candidate afin qu'elle soit délivrée comme finale.

Tests L10n

(en cours de construction...)

L10n QA se concentrera sur les chaînes des nouvelles fonctionnalités introduites afin de pouvoir corriger la localisation à temps avant le gel de la version.

Tests des fonctions

(en cours de construction...)

Le processus de QA de la version prend place pendant la phase de Release Candidate (RC). Le test des fonctions va se focaliser sur les fonctionnalités natives de LibreOffice.

Nous utilisons un outil de gestion des tests Moztrap. Connaître de façon très basique comment fonctionne Moztrap dans le contexte de test de LibreOffice est tout à fait suffisant pour commencer à tester.

Le processus peut être défini de façon spécifique :

  • avant qu'une version Release Candidate soit rendue disponible, l'équipe de maintenance des tests met à jour les cas test et les exécute sur chaque build dans MozTrap.
  • l'équipe de build Libreoffice fait une annonce lorsqu'une RC est disponible pour tests. L'équipe QA peut aussi facilement vérifier la disponibilité d'une pre-release récente.
  • l'équipe QA télécharge la dernière version Release Candidate (RC) et commence à exécuter les cas de test, puis met à jour le résultat de ces tests dans MozTrap
  • en se basant sur les critères de version, tous les tests programmés doivent être terminés au moins 10 jours après que la version Release Candidate soit prête.
  • l'équipe QA annonce les résultats des tests passés ou échoués en fonction des critères de version

Process de QA pour l'accessibilité (a11y)

Cette rubrique est destinée à faciliter les tests concernant l'accessibilité de LibreOffice

  • lien vers le métabug regroupant tous les bugs ayant le mot-clé a11y
  • lien vers les bugs ayant le filtre a11y
  • lien vers les bugs avec LibreOffice et Orca

Process de test sous Windows avec NVDA

  • lien pour télécharger NVDA

Process de test sous Linux/Gnome avec Orca

Orca est déjà présent sur les distributions Linux/Gnome et installé par défaut sous Ubuntu.

Pour le démarrer, saisissez orca dans un terminal et l'application sera lancée. Pour quitter Orca, faites Ctrl+C dans le terminal.

Informations complémentaires pour les testeurs QA

    • Sessions de chasse aux bugs, voir également QA-Projects-Incubator

Rapports / Vérification de rapports de bugs sur les autres outils de suivi

LibreOffice est inclus dans plusieurs distributions, et un certain nombre de système de suivi de bug est listé ici: