Hi,
Tora schrieb:
For when we should do what, there might be some ideas:
(Type A) Comprehensive test at release test;
Feedback from the release test could address to the next
release.
=========== development, translation, integration, ...
========= TCM testing
========= release test on en_US RCs
==================== release test on local RCs
The problem here is, that most of community release testing is done by
the native lang teams. To tell the fact: we have no coordinated
community QA for the en_US release (only Mac has).
This works quite well, as long native lang teams start early to test ..
indeed they would only do so if localized builds are available.
And many functional bugs are found by native lang teams. This is the
reason why I tried to have localized release dates close to the global
release. And .. far less than 50% of our users use the en-US builds.
(Type B) Quick test at release test;
Comprehensive test should be done before the release test.
=========== development, translation, integration, ...
========= TCM testing
========= release test on en_US RCs
========= release test on local RCs
Do the language dependent tests on the earlier builds than release
candidate builds. At the release test, simply conduct a test on basic
functionalities such as installation, typing texts, font rendering,
saving, loading, exporting, printing, copying-and-pasting, and
uninstallation.
If we find some language dependent problems during earlier tests,
we can report them to the developers who can fix them earlier time
of development process.
Delay for fixing problems would be several weeks. And, fortunately,
no casual users would face the problems.
Well .. this is what we actually do. And I do not see, why we should not
continue this way.
André
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
