From 33058f2b292b3a581333bdfb21b8f671898c5060 Mon Sep 17 00:00:00 2001 From: Peter Bengtsson Date: Tue, 8 Dec 2020 14:40:17 -0500 Subject: initial commit --- files/fr/qa/index.html | 60 ++++++++++ files/fr/qa/triaging_bugs_for_firefox/index.html | 135 +++++++++++++++++++++++ 2 files changed, 195 insertions(+) create mode 100644 files/fr/qa/index.html create mode 100644 files/fr/qa/triaging_bugs_for_firefox/index.html (limited to 'files/fr/qa') diff --git a/files/fr/qa/index.html b/files/fr/qa/index.html new file mode 100644 index 0000000000..a84aeb8874 --- /dev/null +++ b/files/fr/qa/index.html @@ -0,0 +1,60 @@ +--- +title: Assurance qualité +slug: QA +translation_of: Mozilla/QA +--- +
+

Il y de nombreuses choses que vous pouvez faire pour aider le projet Mozilla dans le département d'Assurance Qualité, sans être un expert en programmation. Certaines ne nécessitent pas non plus de connaissances en HTML ou autres technologies Web. Si nous aider à tester ou pour d'autres activités d'Assurance Qualité vous intéresse, consultez avant tout les pages Mozilla Quality Assurance et Helping with Quality Assurance.

+
+ + + + + + + + +
+

Documentation

+ +
+
Recommandations pour l'écriture d'un bug
+
Plus un bogue signalé sera précis, plus il y aura des chances qu'un développeur le corrige. En suivant ces recommandations, vous serez assuré que votre bogue reste au-dessus de la pile des ingénieurs de Mozilla et soit corrigé. (à traduire de en:Bug writing guidelines)
+
Comment identifier les rapports de bugs dupliqués
+
Ce guide vous aidera à identifier un maximum de rapports de nouveaux bugs de manière la plus efficace. Cela suppose que vous soyez habitué à la recherche des doublons dans Bugzilla.
+
Comment détecter si un bug a déjà été rapporté
+
Vous pouvez faire en sorte que plus de bogues soient corrigés rapidement en vérifiant la base de données Bugzilla avant de poster votre bug, et ne pas en créer un nouveau si celui que vous avez trouvé existe déjà.
+
Utilisation des expressions rationnelles avec le moteur de recherche de Bugzilla
+
Ce guide fournit suffisamment de connaissances de base et des exemples concrets pour utiliser les autres types de recherche (particulièrement les expressions rationnelles) — et c'est ainsi que vous ferez votre expérience.
+
+ +

Tous les articles…

+ 		+

Communauté

+ + + +

Outils

+ + + +

Tous les outils…

+ + + + + + +
diff --git a/files/fr/qa/triaging_bugs_for_firefox/index.html b/files/fr/qa/triaging_bugs_for_firefox/index.html new file mode 100644 index 0000000000..31510b18c0 --- /dev/null +++ b/files/fr/qa/triaging_bugs_for_firefox/index.html @@ -0,0 +1,135 @@ +--- +title: Triaging Bugs for Firefox +slug: QA/Triaging_Bugs_for_Firefox +translation_of: Mozilla/QA/Triaging_Bugs_for_Firefox +--- +

Ce document aidera toute personne intéressée par la QA chez Mozilla d'apprendre les techniques pour aider avec les bugs tout le long de leur évolution. Il permettra de fixer plus rapidement les bugs importants et d'optimiser l'efficacité de notre communauté Bugzilla. Avant d'entrer dans les détails, il est important de savoir que le Triage  fait ainsi est la raison pour laquelle il est important.

+ +

Qu'est ce que le Triage?

+ +

 Le triage de Bugs est le  processus de déplacement logiques des bugs d'un état à un autre, de sorte qu'ils puissent être résolus d'une manière efficace et facile à comprendre. Chez Mozilla, la QA ne doit pas seulement tester et ensuite déposer leurs propres bugs, mais elle doit aussi aider à exploiter le flux entrant des bugs de la communautés pour trouver des problèmes valides.

+ +

Pourquoi voudriez vous aider?

+ +

Bugzilla est le coeur du projet Mozilla, comme tous les produits, Mozilla suit ses défauts logiciels et les améliorations dans BMO. Il n'y a rien dans le projet tout aussi central ou aussi important que BMO. Le triage est nécessaire pour veiller à ce que tous les défauts signalés sur Bugzilla soient répondu. Un arriéré de bugs dans un Etat quelconque, en particulier l'état UNCONFIRMED, affecte notre capacité à réagir à vos questions importantes rapidement et efficacement. Ainsi, nos déclencheurs de bugs sont incroyablement vitales pour notre développement de produits.

+ +

Préréquis

+ +

Equipez vous

+ + + +

Autorisations Bugzilla

+ + + +

Création de requêtes de recherche sur Bugzilla

+ +

Bugzilla offre deux façons àun utilisateur de trouver des bugs dans sa base de données. Il y a une option de recherche simple et une option de recherche avancée. Chacune offre un moyen unique de recherche qui permet à l'utilisateur une certaine souplesse dans la façon dont ils veulent effectuer leur recherche. A simple search will only restrict search parameters to any currently not-fixed bug that match the string input by the user. Meanwhile, the advanced search form allows the user the ability to really cut down on any glut found through a simple search. But it can be a bit confusing. So, Bugzilla offers a "Give me Some Help" hyperlink located in the top left portion of the form that reloads the page with hover-enabled tool-tips to guide you through each module. This link also give you more information about searching in Bugzilla.

+ +

Persistent Queries and how to Manage them

+ + + +

Tracking Components

+ +

If you want something more immediate, you can choose to track a component, such as Disability Access. This is possible via your Bugzilla preferences using the "Component Watching" option. Make sure to track the relevant component in both Core->Disability Access APIs and in the products you care about, such as Firefox (Firefox->Disability Access) or Thunderbird.

+ +

Clean incoming Bugs

+ +

Why is it Important?

+ +

Ensuring bugs are properly marked helps make sure they don't get ignored. For example, if a bug that really affects all platforms is marked "Solaris" because the original bug author was on a Solaris machine, most developers will ignore it. Other common issues include major bugs that are marked normal, bugs with a confusing summary, etc. So, ensuring that the bug is properly marked is very helpful in getting the attention it deserves.

+ +

What would Speed Up the Process?

+ +

Each time you submit changes to the bug it creates extra Bugmail, so it's better to do the following steps in batches, if possible.

+ + + +
+

Steps to Reproduce

+ +

Sometimes, a bug report contains no steps to reproduce or steps that only work for very few people. In that case, it is extremely difficult for a developer to debug and fix the reported issue. Most of the time, these bug reports (and crash reports, where applicable) will contain multiple clues or variations of steps and it is needed for someone to work through them and narrow down reliable steps to reproduce. Here are a few guidelines for narrowing down those steps:

+ + + +

Minimal Test Cases

+ +

Reporters usually add to their bug reports the links for the web pages they saw issues on. Some of these pages are very complex, making it quite difficult to realize where or why the bug happens. To help investigate and debug a issue with a complex web page, you first need to reduce it to a minimal test case (i.e. a test case that contains the minimum set of elements that reproduces the issue). Here are some steps for using the process of elimination to create a minimal test case:

+ + + +

Hopefully you'll be left with a file that has only 1-5 HTML elements in it, but still reproduces the bug. At this point you can actually try to start stripping out irrelevant attributes as well You may end up with something like: <label for="myfile">Enter file name:</label><input id="myfile" disabled="disabled" type="file"> ...instead of 50k worth of HTML. When finished, attach the minimal testcase, mark the bug with keyword testcase, and change the bug summary if necessary. For example, "No borders in tables at http://www.sillystatsandstuff.com" can become something much more precise such as "tables with rowspans do not get borders". If it doesn't affect the test - add a title so it can be referred to, e.g <title>Testcase #1 for bug 123456. Also, add the bug number in the filename of the testcase. You have to understand that people from different parts of the world will be reading this, so making concise and direct sentences are much appreciated. For example, if the bug involves line wrapping, then the width of the window and the font size may impact the results. In this case, you can ensure that your reduced testcase will work for everyone by using "font-family: monospace;" and a width specified in "ch" units.

+ +

What do I take away from this?

+ +

This can all be rather intimidating for people who haven't been playing around with different web technologies such as AJAX, JS, or XML for a long time, but the most important thing to take away from this page is that there's a backend to the bugs you find when interacting with any software, hardware, or general product. Make sure to take that into account when writing your next bug or triaging a host of incoming bugs on Bugzilla! Continue reading all about Finding a Regression Window.

+ +
+
+

Original document information

+ + +
+ +

 

-- cgit v1.2.3-54-g00ecf