Bienvenue
Cette page précise toutes les activités dans lesquelles vous pouvez vous impliquer pour participer à l'assurance qualité (QA) de Fedora. Elle est faite pour vous guider dans l'écosystème de l'assurance qualité. Devenir un contributeur est une chose facile et nous vous accueillerons avec plaisir. La première chose que vous désirez certainement c'est d'être mis en relation avec toutes les sources d'information de l'assurance qualité de Fedora.
Il y a cinq étapes à franchir pour accélérer votre participation à QA (dans un ordre de priorité approximatif) :
- Souscrire à la liste de diffusion test
- vous auto-présenter à l'équipe
- Créer un compte Bugzilla (cela devrait être l'adresse que vous utiliserez en créant votre compte FAS dans l'étape suivante)
- Créer un compte FAS (Fedora Account System) et rejoindre le groupe QA de FAS
- Rejoindre le canal IRC #fedora-qa[?] sur Freenode
Qu'envisagez-vous de faire ?
Que vous envisagiez de tester une version stable, un nouveau paquet de updates-testing, une pré-version dans une branche, ou le développement le plus avancé que représente la version Rawhide, il y a un endroit pour vous pour participer à l'assurance qualité de Fedora. Nous avons besoin de personnes qui aiment appuyer sur tous les boutons, utiliser toutes les options en ligne de commande, vérifier toutes les documentations, passer en revue les choses sous l'angle de la convivialité et suggérer des fonctionnalités pour l'avenir – en particulier pour tout ce qui a entrepris des changements majeurs dans une version récente ou sur le point de paraître.
Si vous désirez :
- Travailler sur une version stable prête à paraître
- Travailler sur le test de mises à jour de paquets
- Travailler sur la version Rawhide
- Tout ce qui précède
Si vous désirez faire autre chose
Pour toutes ces tâches, il serait bons d'être familiarisé avec notre instance de Bugzilla. Beaucoup de contribution à Fedora arrivent par le signalement de bogues. Tout ce qu'il vous faut c'est un compte Bugzilla : créez votre compte. Assurez-vous d'utiliser la même adresse de courriel pour votre compte FAS et pour votre compte Bugzilla. Notre Our guide des bonnes pratiques de signalement de bogues vous précise l'essentiel à connaître pour signaler des bogues. Si vous voulez discuter sur les bogues avant de les signaler, vous pouvez contacter les membres de QA sur la liste de diffusion test et sur le canal IRC #fedora-qa[?].
Specifics
Introduce yourself and join the team!
Before getting stuck in, why not introduce yourself? It's not compulsory, but we like to say "hi!" to new members. Just subscribe to the test mailing list and send a mail with a topic like "Self-introduction: (Your Name)". Just say that you're interested in helping with QA, include your IRC nickname if you have one, and, if you like, include some information on your Fedora / Linux background. Here's an example mail.
Testing official package updates before they are released
Another easy way to contribute to Fedora QA is to help test official updates for stable Fedora releases before they're released. See QA:Updates Testing for instructions on how to test and report issues with these updates.
Testing Fedora pre-releases
Before an official Fedora release comes out, Alpha and Beta builds - known collectively as pre-releases - are made available. You can contribute by installing these pre-releases and testing them, just as you would a stable release. If you continuously run the pre-release and update regularly you can also provide feedback ("karma") to candidate update builds - effectively doubling the number of things you can test. For information on getting and installing pre-releases, see this page. Report any issues you find to Bugzilla - complete instructions are here: BugsAndFeatureRequests.
Release validation
The QA group co-ordinates planned testing of the installation process and basic functionality before each Fedora release and pre-release is made, to ensure they reach certain standards known as the Fedora Release Criteria. See the release validation test plan page for more information on this process and how you can contribute to it. Also look out for mails to the list that announce composes "nominated for testing" - these mails contain instructions.
Testing Rawhide
Rawhide is the development version of Fedora. Running Rawhide isn't for everyone, but for moderately experienced users who have a spare test system available or can run it in a virtual machine, testing Rawhide is a great way to contribute to ensuring future releases will be high quality. See Rawhide page for instructions on how to install or upgrade to, and test. You can test Rawhide without ever needing to install it by using the nightly live builds.
Joining Test Days
The Fedora QA group holds regular Test Days, where we get together on IRC and test a specific aspect of Fedora, often with the involvement of a developer who works in that area. See the Test Days page for more information on when and where these are held, and how to join in or even schedule one of your own. This page should always direct you to the current, most recent, or soon-to-happen Test Day - see if it's one you'd like to join in!
Creating test cases
As well as simply keeping a look out for problems, the QA group develops structured test cases and test plans. See the Category:Test Cases and Category:Test Plans pages for information on the test cases currently available. The test case creation process will tell you how to create test cases.
Developing tools
Some members of the Fedora QA team are involved in developing and maintaining tools to help make testing more efficient. Some of the tools we wrote that are already in use (but under constant development!) include Taskotron (which replaced the older AutoQA), python-bugzilla and the blocker bug tracking web app. We also use Bodhi, Bugzilla and fedora-easy-karma. Tool development is a great way to apply engineering skills to QA. Drop by the #fedora-qa[?] IRC Channel or the qa-devel mailing list if you want to get involved building tools.
Triaging and managing bugs
Once bugs are reported, QA should make sure they are addressed by the right people and don't get stuck in the process.
What is Involved in Bug Triaging?
Bug triagers make sure that:
- Bug reports have the information developers need to reproduce and fix them.
- Bugs are assigned to the right component and version.
- Duplicate bugs are found and labelled.
- Feature requests reported as bugs are properly reported.
- Bugs already fixed are closed.
The mailing list is a great place to raise any questions or problems you are having. Experienced QA Members are more than happy to act as mentors for new members to help them get started with QA. Triaging bugs does not mean that you have to understand the bugs and solve them yourself. It simply means you should be able to look at new bugs, and report if they are duplicates, if more information is needed, or if it is filed under the wrong component.
There is no requirement of programming knowledge. However, being familiar with Fedora and Linux in general will be extremely useful. A more complete guide is here.