Title: Introduction to QA Notice: Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at . http://www.apache.org/licenses/LICENSE-2.0 . Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the 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. To complete this module, read through the material on this page, including the linked references. There will also be some start-up tasks for you to perform, such as signing up for an account in our defect tracking database. Your first task is to subscribe to our QA mailing list and to introduce yourself to the other QA volunteers. You can subscribe by sending an email to [qa-subscribe@openoffice.apache.org](mailto:qa-subscribe@openoffice.apache.org). Then you can introduce yourself by [sending an email to the list](mailto:qa@openoffice.apache.org?subject=New QA Volunteer). We'd love to hear who you are, where you are from, what your background is, etc. Also as you work through the items on this page, if you have questions or problems, please feel free to ask for help by sending a note to this same list. Note: In parallel with the QA-specific items on this page, you may want to first review the [Level 1 and Level 2 Orientation Modules](http://incubator.apache.org/openofficeorg/orientation/index.html) as well. They have useful background information on The Apache Way, mailing list etiquette, decision making in the project, etc. A quick review is a good idea, especially if you are new to working in Apache-style open source projects. Now with the introductions out of the way, let's get started with the 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. Since OpenOffice is a core software application for millions of users, the role of QA is critical. Although our programmers are wonderful, talented and very experienced, they do make mistakes. Our task is to find these mistakes, report, prioritize them, and verify the fixes when they are made. 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? As a volunteer why would you want to help with OpenOffice QA? A few things to consider: - We're a fun, international group of testers, of a range of skills and experience, dedicated to free software and making OpenOffice a high quality choice for users. - This is a good way to learn about QA and get some practical experience. This is useful, for example, if you are thinking about Software Quality Engineering (SQE) as a possible career choice. - Helping as a tester is a good way to "give back" to the open source community in a way that makes a direct difference in the product, but doesn't require programming skills. - It is a good way to raise the visibility of bugs in your particular interest area. For example, maybe you personally are concerned about bugs that cause problems on the Mac, or bugs that impact color blind users, or bugs related to bidirectional text. Participating on the QA team is a good way to ensure that areas of personal interest are adequately tested. - 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 within the Apache OpenOffice project include: - Reviewing incoming bug reports from users to see if the reported issues can be reproduced - Verifying bugs that the developers say they have fixed, to confirm that they actually have been fixed - Testing new builds of OpenOffice against a functional test plan - Defining new test cases - Running automated regression tests - Specialized tests in areas such as performance, accessibility, localization, security, etc. - Analyzing defect reports to gauge how we are doing, in terms of quality level, defect find and fix rates, etc. - 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 The skills we need on the QA team include: - Familiarity with OpenOffice as a user. - Attention to detail. In QA we find the bugs that the developers missed. And our developers are pretty good. - Access to a Windows, Mac or Linux machine for testing - Good written communications - Interest, enthusiasm and teamwork. - Ability to volunteer at least 2 hours/week, on average. 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 As mentioned above, QA volunteers need to subscribe to our dedicated QA mail list. The mailing list is for bug reports, quality assurance for release, beta tests, manual test, automated tests, etc. This is where the QA community coordinates its activities. Subscribe: [qa-subscribe@openoffice.apache.org](mailto:qa-subscribe@openoffice.apache.org)
Post (after subscription): [qa@openoffice.apache.org](mailto:qa@openoffice.apache.org)
Unsubscribe: [qa-unsubscribe@openoffice.apache.org](qa-unsubscribe@openoffice.apache.org) Archives: - [Markmail](http://markmail.org/search/+list:org.apache.incubator.ooo-qa) - [Apache](http://mail-archives.apache.org/mod_mbox/incubator-ooo-qa/) We use the following special subject tags to identify QA activities: * [QA REPORT] - topic related with status report * [QA AUTOMATION] - topic related with automation tools, scripts and scope * [QA BUG] - topic related with bug discussion * [QA CRITICAL] - important information related with QE * [QA CALLFORREVIEW] - topic with some review * [QA CALLFORVOLUNTEER] - if you want to call for volunteer for testing some features * [QA] default if others don't fit. After you subscribe QA mail list then you can post your topic in the mail group. ##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! Some volunteers simply use two machines: one dedicated to their testing work. If things become unstable they can then reinstall the operating system and start fresh. A more sophisticated approach is to use virtual machines, which can work quite well. [VirtualBox](http://www.virtualbox.org) is a popular visualization package. Feel free to ask questions on the QA list about effective ways to manage a test environment. Once you have your test environment set up, you need to download and install the latest OpenOffice build. - [AOO nightly build](http://ci.apache.org/projects/openoffice/index.html) are built each night and are our "rawest" builds, with many possibilities for finding new bugs. - [Snapshot builds](https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds), are made generally every few weeks, are built in multiple languages and platforms. ##Bug Handling Apache Bugzilla is where we track defects: * [http://issues.apache.org/ooo](http://issues.apache.org/ooo) Bugzilla related documents: * Bug lifecycle introduction [Issue Lifecycle](http://wiki.openoffice.org/wiki/Issue_lifecycle)
* A guide for reporting a new bug: [How to file bug](http://wiki.openoffice.org/wiki/QA/HowToFileIssue) Everyone in QA needs a Bugzilla account, which you can get [here](https://issues.apache.org/ooo/createaccount.cgi). Once you have a Bugzilla account, you should send a note to the QA list asking to be added to the QA role in Bugzilla. This will give you some additional permissions in Bugzilla. Include your Bugzilla login ID in your request. ##Easy QA Tasks The two easiest tasks for a new QA Volunteer are: - Verify bug fixes. This helps you gain familiarity with the OpenOffice product, and our process. This verification is also very important, since some bug fixes either fail to fix the bug, or cause a new bug. - Manual testing. This gains you further familiarity with QA process, by executing pre-defined test cases and writing up defect reports for any new defects found - Writing new test cases. 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. ### Verifying Fixed Defects You can get resolved bug list from this query: [All fixed bugs after AOO 3.4 release](https://issues.apache.org/ooo/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=Fixed_After_340&sharer_id=248432) Select the bug you want to verify: 1. First you need to understand which fault does the defect report is referring to. 1. Install the latest build. 1. Follow the steps to reproduce and check to see if the defect has been fixed. 1. Add additional comments to the bug with your test result. e.g. build revision number, platform you have been tested etc. 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" (this action requires "CanEdit" privilege" in Bugzilla system, if you cannot do that then send mail to mailing list and ask other QA do this for you.) ###Manual Testing To get more familiar with AOO, now you can try to perform some manual test cases. - Browse test management tool, [Testlink](http://aootesting.adfinis-sygroup.org) to find available test cases.
- Read this guide if you are not familiar with Testlink tool. [Testlink usage guide](http://wiki.openoffice.org/wiki/QA/Testlink ) ###Test Case Authoring After some practice on test case execution, now you can start writing new test cases. Useful guide for writing manual test cases: * [A guide for writing test case](http://wiki.openoffice.org/wiki/QA/Testcase/How_to_write_test_case) * [A simple test case sample](http://wiki.openoffice.org/wiki/QA/Testcase/Sample) ## Module Completion Once you have done the above, go to our our [Directory of Volunteers](https://cwiki.apache.org/confluence/display/OOOUSERS/Directory+of+Volunteers) wiki page and add or update your information. Congratulations! Please send a note to [qa@openoffice.apache.org](mailto:qa@openoffice.apache.org?subject=Completed Introduction to QA) so we know.