OOo QA Participation Steps

From Apache OpenOffice Wiki
Jump to: navigation, search

Lesson 1: General Overview

(week 1)

  1. Get a general overview over the AOO QA project and how it works Quality Assurance and AOO QA Strategic Concept Papers
  2. Make familiar with reporting bugs, especially issue handling: Quality Assurance Report Bugs
  3. Register at AOO as firstname-HitekSchool
    • An OOo e-mail address [YOUR_NICK]@openoffice.org is automatically generated
    • The [YOUR_NICK]@openoffice.org address is shown as sender if the mail is generated by the issue tracker
  4. Try mailing list qa@openoffice.apache.org from QA Mailing lists. You can find Introduction to General & Project Mailing Lists here.
    • Just say hello if you do not have any tasks/questions.
  5. Try IRC channel: please find and install an IRC client that suits for you (there are a lot of free tools on the Internet. You can take a look into this list of IRC clients and pick up one which is most convenient for you. Basically, Opera chat tool works pretty well).
  6. Create a 'calling card' in oo wiki like: User:Oleg-HitekSchool (Find instructions on wiki help).
    • Our Wiki pages should be in Hitek School Category
    • You should include your AOo email address there
    • Please, don't create drafts or unneeded pages, wiki documents or contents cannot be permanently deleted, and all changes are saved.

Lesson 2: Issue Handling

(week 2-3)

  1. Install office developer version and try different applications: https://www.openoffice.org/download/index.html
    • Find out what you need for your system and install office developer version on your computer.
    • You can try to work with it and reveal issues. For reporting them, you need to use Bugzilla.
  2. Issue tracker:
    • make familiar with the tooling
      • basic rules you should know before sending Issues,
      • bug lifecycle,
      • the way to query an issue and to track it
    • take a look at Quality Assurance - Report Bugs
      • make familiar with Issue Handling, Issue Enter
    • have a look on some issues in real and how they are handled - status changing from unconfirmed to closed
    • write a test issue (and send its number to your group lead).
    • When you find a problem in the application, you need to find if it is already in the issue database before submit a new one
      • check whether similar issue is already described (including duplicate and closed)
      • pay attention to platform, OS and version - you can miss existing issue if you don't choose suitable parameters
  3. Confirm 10 issues
    • each team site from Quality Assurance has a link called 'open issues'. Have a look inside several issues and try to reproduce them on your system (try different application); write in the issue: "I can reproduce that on system … with version … etc. (check how others handles such things) and send the collected issue numbers to your group leader. You need to log in for doing this.
    • If you have comments that didn't confirm an issue but could help to clear them, is welcome. If you cannot confirm, it mostly had reasons: description is not proper or imprecise, example is not attached etc. and in this case this is also a good comment f.e.: 'I cannot reproduce it like described, please add a step by step description'
  4. Make familiar with the EIS tool. deprecated
    • Look, which CWS is already integrated in which version. If you try to check a fixed issue in a version where the CWS (containing the fix) is not integrated, you get confused why it is not fixed or think it is not properly fixed etc.
  5. Close 10 'verified issues'
    • site Sitemap of the Quality Assurance Pages has a link called 'Integrated Issues'. Check if the bug is fixed in a master version (must be already integrated, therefore check in the EIS tool deprecated).
    • If yes - write in the issue something like: "verified in XY master version - can be closed" (you don't have canconfirm rights to close it by yourselves for now) and send the collected issue numbers to your group leader.
    • send your group lead the collected issue numbers
  6. Join an irc chat 'issue cleaning session' if it is announced

Lesson 3: Manual Testing / TCS

(week 4)

  1. Get a general overview about TCS.
  2. Execute 3 existing TCS-s.
  3. Take a look at specification in general.
  4. Write TCS from the spec (about 30-50 lines/steps) and compare it to the existing one (if any).
  5. Write a TCS that does not exist (with or without SPEC).

Lesson 4: Automated Testing (not obligatory)

(week 5-7)

  1. Make familiar with the automation area in general: OO QA-TeamAutomation and Automation tooling
  2. Try the tooling and run an automatic test
  3. Take your TCS and make an auto test from it
  4. Overwork your TCS, whether it fits for manual and auto test.

Lesson 5: Questions & Answers

(week 8)

  1. Reflect what you have learned, ask open questions and finish your documentation


Lesson 6: Individual Project (not obligatory)

(month 1-3)

  1. An individual project (depending on the interests of the single students and the needs of the OOo QA project) in classical QA areas like:
    • Issue Handling
    • TCS
    • Automation
    • Document Writing
    • Individual Tasks






Authors: Oleg Rodov, Natalia Polioudova (concepted by Christoph Lukasiak). 28 December 2008

Please do not change the logical content of this site without acknowledge of the author or the OOo QA Project Lead/Co-Leads.

Personal tools