OOo QA Participation Steps

Step 1: General Overview

(week 1)

1. Get a general overview over the OO QA project and how it works Quality Assurance and OOo QA Strategic Concept Papers
2. Make familiar with reporting bugs, especially issue handling: Quality Assurance Report Bugs
3. Register at OOo as firstname-HitekSchool@openoffice.org
   • An OOo e-mail address [YOUR_NICK]@openoffice.org is automatically generated
   • The @openoffice.org address is shown as sender only if the mail is generated by the issue tracker
4. Try mailing list dev@qa.openoffice.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 in 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).
   • The IRC channel on the Freenode server irc://irc.freenode.net/ for this QA project is #qa.openoffice.org
   • OpenOffice.org's localization community hangs out at channel #ooonlc
     • You can say "Hi" and Bye" and disappear very quickly, if you like.
6. Try OO wiki (create a simple XXX page and send the link). Find instructions on wiki help.
   • Please, don't create drafts or unneeded pages, wiki documents or contents cannot be permanently deleted, and all changes are saved.
7. Create a 'calling card' in oo wiki like: User:Oleg-HitekSchool and connect it with earlier created page
   • You should include your OOo email address there

Step 2: Issue Handling

(week 2-3)

1. Install office developer version and try different applications: http://download.openoffice.org/680/index.html
   • Find out what you need for your system and install office developer version at your computer.
   • You can try to work with it and reveal issues. For reporting them you need to use Issue Tracker.
2. Issue tracker:
   • make familiar with the tooling
     • basic rules you should know before sending Issues,
     • bug lifecycle,
     • the way to query issue and to track it
   • have 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 team lead)
     • check whether similar issue is alreagy 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 team 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: discription is not proper or unprecise , 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.
   • 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).
   • 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 team leader.
   • send your team lead the collected issue numbers
6. Join an irc chat 'issue cleaning session' if it is announced

Step 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).

Step 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 that it fits for manual and auto test (auto test documentation)

Step 5: Questions & Answers

(week 8)

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

Step 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 Polyudova. 28 December 2008

Mentor of the Intership program: Christoph Lukasiak

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