Andre Schnabel wrote:
*sigh* seems we really need to write down the process and collect
sources where we already have written down something ...
Yes, it seems...
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.
Exactly.
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 ;-)
So do I. The test items Andre has chosen and listed in the TCM are
sufficient for release.
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.
That sounds nice. I apologize for not knowing the ability of the TCM well
and thank you for the information.
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.
Correct.
Issue 72618 might be another good example.
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
Agreed.
Best regards,
Tora
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
