Hi Maho, Andre,
Funny, I was answering Maho's mail but now I'll jump through your lines ;)
Andre Schnabel wrote:
Hi Maho,
NAKATA Maho schrieb:
[This is under development; and I'm very narrow sighted person, thus
feed back is very very very welcome]
maybe it's better to have this at the wiki and edit there?
I think it's ok here others can jump may be more easily in the discussion
....
1. How to get started with QA?
better How to get started with localization QA
"QA" is really more than testing OOo and verifying that it doesn't crash
;-)
Yes I agree with you that l10n QA is part of the two round of QA tests.
....
2. The QA process.
For each localized builds, quality assurance (QA) must be passed to
official
release of the builds. Each native language team, localization team
and porting team
must elect QA responsibility person(s) to conduct QA. QA
responsibility person
must test release candidate (RC) builds, and do some test, if test is
done, then
say "GO", and released.
Hmm .. the person who approves a build does not need to do the tests
herself. If there are enough helping hands, It is much better to "just"
organize and review the work. So the one who is responible for QA must
make sure, that the builds are tested and needs to be aware of the test
results.
(I hope somenone could make short sentence from that?)
Two things here: I agree with you Andre that the QA lead doesn't need to
be the tester. However if this is the QA lead that fill the bug, it's
better for him to check how to reproduce the bug, not that the tester is
not trusted but for a better description. Usually I only run the failed
tests on TCM.
....
3. Which packages should be QA'ed?
For example, there are some packages for Japanese(and or your fav. lang)
for OOo2.1RC2.
I'd make this more generic. e.g.
In general all packages should be QA'ed. But as ressources are limited
you should focus on those platforms that are important for your users
and those where you have enough volunteers to test the builds. It
doesn't matter if you do QA on Sun builds or builds provided by other
community members. SImply do QA on those builds you like to distribute
as your final version.
+1
(Ok, in fact it is doese matter what builds you do QA on, as "regular"
used builds get more attention and more testing. Doing QA on Sun builds
or those provided by Pavel or Maho would reduce the risk of bugs.)
4. What should do in QA for release?
It is up to QA responsibilities. We respect decision by QA
responsibilities.
Here are some recommended way of tests
* Using TCM (Test Case Management).
How to use TCM?
http://wiki.services.openoffice.org/wiki/Test_Case_Management
* Using automated QAtool.
How to use QAtesttool for personal use? See [QA] for example.
We recommend to use TCM.
Hmm... the Release Sanity scenario has also some automated tests. So you
would use both tools. And that's what I would recommend ;-)
Yes and confirm bugs found by the testool by manual tests is often better.
5. Tracking QA
QA status of localized builds can be found at
http://www.qatrack.org/ooo/view.php
6. Writing Issue
If some localized builds are approved, you should write an issue so that
distribute QA'ed packages are distributed worldwide (congratulations!)
Here is a list that request packages are QA'ed and mark as `release'
and distribute to the mirrors.
How to write issues? You should learn from following issues.
Esp. http://www.openoffice.org/issues/show_bug.cgi?id=72468 (German)
might help you ;)
I put a "template" to the wiki:
http://wiki.services.openoffice.org/wiki/Release_Action_List_for_QA#Approval_of_localizations
Thank you both for this :-)
Kind regards
Sophie
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
