Hi,
*sigh* seems we really need to write down the process and collect
sources where we already have written down something ...
And all would lead to the conclusion, that QA for localized builds
cannot be a separate thing but needs to be embedded in a larger process.
....
Tora schrieb:
Great. It clearly states what we should do on our localized builds
to distribute them to the local market.
I am not sure that the following idea could be put in the same page
or in the separated page. It is a position of the local test within
the development process of OpenOffice.org. Have a look at schedule
in the web page http://wiki.services.openoffice.org/wiki/OOoRelease21 .
....
In the list, the local test is positioned in the very end of the
process, from release candidate to product release.
Yes, because this schedule focuses on a single release. Please read
http://wiki.services.openoffice.org/wiki/Release_Action_List_for_QA
what is more general (but still focused on Release)
===
What and what for should we test on our local builds to release them?
===
The question could be divided into several small questions:
- What should we test mainly at a period of local test and why?
Speaking of the tests for release approval:
- test very basic functionality to be sure, users can work with your
build, that it can be installed at all, has no viruses ... although the
source code might be without any bugs, we might introduce bugs in the
build process .. and some of them can affect just one single language ..
so .. it needs to be tested.
The RElease Sanity Scenario in TCM has been created for exactly this
purpose. Well .. I got exactly zero comments about test to add to (or
exclude from) this scenario - so I think it must be perfect ;-)
- What should not we test at the moment, which would spend time
and make a delay of release process.
- (For the next step) How can we eliminate redundancy of test efforts
among local communities? The primary functionalities of OpenOffice.org
are language independent and identical to every local version.
Theoretically, local communities could share test results on the
primary functionalities.
Use TCM! And Use TCM at a very early stage! File Issues and link them to
TCM!
Each Language Manager can access the results of other languages. So it
is easy to browse failed Test Cases of other languages and check those
again in your language. Once an Issue is filed, it is very easy to see,
what the problem is.
If an Issue has been linked to a test case, other testers will see this
information and can have look at the issue, if this affects the own
language as well.
Use Issue Tracker - and use mailinglist (for possible stoppers). Please
use the qa mailinglist for important issues. It is great to have
discussions about stoppers within the native lang teams or platform
related teams (like Mac) - but it is better to have them spread, so we
can see if other users would be affected and prioritize the issue correctly.
I hope, we get someone working on a testtool result database next year.
This would ease the work with automated tests a lot. E.g. Instead of
duplicating work, we could focus on critical areas.
Answers to the questions could be put somewhere close to the web page.
One thing that we could consider:
The primary and language independent functionalities had been tested
by development team and QA team before our local test.
Hmm .. good assumption. The problem is ...
What had not
been tested so far?
We don't know about that ;-) We have some knowledge, what have been
tested .. but we do not know what has *not* been tested (ok, the only
thing that might be true ist to say "a lot").
What is difference among local environments?
First .. what is the difference between a developers / developer centric
QA environment and "localized tester" environment:
In most cases, a developers environment is well defined - it is "clean".
This is a precondition for correct testing. If it wasn't so, you would
never know, if an error occured because of a bug you just implemented or
because of your environment.
A localized testers environment is closer to a real users environment
(at least from my experience) - it is "polluted" just like a users
environment. But this will reveal robustness problems of our software
(issue 72272 is a good example).
And of course there are differences between local environment - fonts,
UI styles, IME's .. but also file systems, path names, versions of
installed libraries .. and a huge amount of different OS versions.
That would be keyboard, input method, font rendering,
date-time-currency
format, printing to printers that locally purchased, interoperability
with competitor's software turned and tweaked to the local market,
and so on.
Correct ;-)
We should test language dependent functionalities sometime during
the entire development process. But, they obviously should not be
done at release test. It is too late and time consuming.
Correct .. and that's why we do a call for localization (TCM) testing -
http://wiki.services.openoffice.org/wiki/Release_Action_List_for_QA#Feature_Freeze_and.2For_UI_Freeze
André
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
