openoffice-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject svn commit: r1807043 - /openoffice/site/trunk/content/orientation/intro-qa.mdtext
Date Sat, 02 Sep 2017 12:08:21 GMT
Author: mseidel
Date: Sat Sep  2 12:08:21 2017
New Revision: 1807043

Small changes


Modified: openoffice/site/trunk/content/orientation/intro-qa.mdtext
--- openoffice/site/trunk/content/orientation/intro-qa.mdtext (original)
+++ openoffice/site/trunk/content/orientation/intro-qa.mdtext Sat Sep  2 12:08:21 2017
@@ -16,7 +16,7 @@ Notice:    Licensed to the Apache Softwa
            specific language governing permissions and limitations
            under the License.
+## Introductions
 In this orientation module you will learn how Quality Assurance is done in our community.
You will also learn about basic tasks that are easiest to do for new QA Volunteers.
@@ -30,7 +30,7 @@ Note:  In parallel with the QA-specific
 Now with the introductions out of the way, let's get started with the QA!
-##The Purpose of QA
+## The Purpose of QA
 Our goal is to maintain and improve the quality of Apache OpenOffice. We primarily accomplish
this by finding defects (bugs) in the product before it is released to the general public.
The defects are found by a combination of manual and automated tests that we perform on pre-release
builds of OpenOffice. We also review and try to reproduce 
 defects reported by end-users and submitted to us.
@@ -39,7 +39,7 @@ Since OpenOffice is a core software appl
 QA is a discipline with many best-practices related to process and methodology, tools, techniques
and theory. Although professional QA practitioners are welcome in this project, we are also
happy to welcome those with no prior experience, or those who are learning about QA, perhaps
as a possible career. Aside from the satisfaction of improving the Apache OpenOffice product,
you can learn or practice new skills.
-##Why Help with QA?
+## Why Help with QA?
 As a volunteer why would you want to help with OpenOffice QA?  A few things to consider:
@@ -50,7 +50,7 @@ As a volunteer why would you want to hel
   - We have tasks for volunteers with a range of skills. From novices who can help with manual
testing and fix verifications, to experts who can help with our test automation framework,
we have a full range of QA activities.
   - As an extremely popular open source product, with many millions of users, there are opportunities
here to do some new and exciting things on the QA front, including possibilities of crowd
sourcing some kinds of testing.
-##QA Activities
+## QA Activities
 QA activities within the Apache OpenOffice project include:
@@ -64,7 +64,7 @@ QA activities within the Apache OpenOffi
   - Reporting summary defect data and recommending whether a give build of OpenOffice has
reached a sufficient quality level for release.
   - Making recommendations for improving product quality and testing effectiveness.
-##Skills Wanted
+## Skills Wanted
 The skills we need on the QA team include:
@@ -77,7 +77,7 @@ The skills we need on the QA team includ
 QA is as much an attitude as it is a skill set. A tester likes solving puzzles, likes a methodical
approach, likes the challenge of finding an elegant way to reproducibly break software.
-##Mailing List
+## Mailing List
 As mentioned above, QA volunteers need to subscribe to our dedicated QA mail list.
@@ -102,7 +102,7 @@ We use the following special subject tag
 After you subscribe QA mail list then you can post your topic in the mail group.
-##Apache OpenOffice Test Builds
+## Apache OpenOffice Test Builds
 Since our job is to find bugs in OpenOffice, we must run pre-release builds that contain
many bugs. These bugs could be major or minor. They could include document corruption bugs,
crashes, even (in rare cases) bugs that could make your system unstable. So QA volunteers
generally try to separate their QA work from their normal desktop activities. You don't want
to write your thesis on a test build!
@@ -117,7 +117,7 @@ Once you have your test environment set
   - [AOO nightly build]( are built each
night and are our "rawest" builds, with many possibilities for finding new bugs.
   - [Snapshot builds](, (tagged with
the word "Snapshot") are made weekly against a code branch that is being considered for a
release candidate.
-##Bug Handling
+## Bug Handling
 Apache Bugzilla is where we track defects:
@@ -134,7 +134,7 @@ Bugzilla related mailing list:
 Everyone in QA needs a Bugzilla account, which you can get [here](
Once you have a Bugzilla account, you should send a note to the QA list asking to be added
to the "qa-team" group in Bugzilla. This will give you some additional permissions in Bugzilla.
Include your Bugzilla login ID in your request.
-##Easy QA Task: Confirm New Defect Reports
+## Easy QA Task: Confirm New Defect Reports
 Most new volunteers start by reviewing incoming defect reports and attempting to "confirm"
them. The defect reports are often from users and are often not very clearly written. You
learn to "read between the lines" and ask the user clarifying questions in order to turn the
raw report into a reproducible defect that the developers can debug and fix.
@@ -163,7 +163,7 @@ bug given these steps in the current ver
 Finally, think of the confirmation process as the opportunity for the QA Team to improve
the value of information we receive from users. We're taking the raw bug reports, sorting
through them, eliminating the ones that do not report new bugs, and then passing on the good
ones to the programmers. So anything you can do to improve the quality of the incoming defect
reports will help. This includes clarifying the steps needed to reproduce the problem, attaching
sample documents that you might create to reproduce the
 problem, improving report titles to make them more accurate/relevant to the real issue, correcting
classifications and adjusting defect priorities.
-##Easy QA Task: Verifying Fixed Defects
+## Easy QA Task: Verifying Fixed Defects
 Verifying bug fixes (re-testing a bug report after a developer has fixed it) is also very
important, since some bug fixes either fail to fix the bug, or cause a new bug.
@@ -178,7 +178,7 @@ Select the bug you want to verify:
  1. "Test around" the bug to make sure that nothing was broken when fixing it. You will develop
and intuition for this as you learn to "think like a bug".
  1. Change defect status to "Verified" 
-##Easy QA Task: Manual Testing
+## Easy QA Task: Manual Testing
 Manual testing gains you further familiarity with QA process, by executing pre-defined test
cases and writing up defect reports for any new defects found.
@@ -187,7 +187,7 @@ To get more familiar with AOO, now you c
   - Browse test management tool, [Testlink]( to find
available test cases.  
   - Read this guide if you are not familiar with Testlink tool. [Testlink usage guide](
-##Easy QA Task: Test Case Authoring
+## Easy QA Task: Test Case Authoring
 This is a more advanced topic, but after mastery of the above two steps, and learning to
"think like a bug", you will be ready for this.
@@ -198,6 +198,6 @@ Useful guide for writing manual test cas
  * [A guide for writing test case](
  * [A simple test case sample](
-##Module Completion
+## Module Completion
 Once you have done the above, go to our our [Directory of Volunteers](
wiki page and add or update your information. Also, add an entry for yourself to the [QA Testing
page. Congratulations! Please send a note to [](
Introduction to QA) so we know.

View raw message