Hi Sophie,
it's not so easy to answer. I am not a friend of doing useless work or
time consuming testing which does not identify any problem over a long
time. So I am not a friend of doing all TCM tests for each release
again and again. I said that often. We need sanity checks for the
releases (perhaps the existing ones have to be expended) which tests
some critical points (e.g. does spell checker works, is it still
possible to write/save/load files in the tested language etc.). For new
languages all TCM tests are very helpful to identify easily language
depended issues. But do you think all these test cases make sense
on a stable language, which is released and tested since years? I think
it take a mass of time, but the result will be that the known issues
still exists and new ones aren't came up.
The test case specifications for general testing of functionality (new
feature or older functionality) are more complex, as the test cases in
TCM. Therefore my team asked for new features in TCM, when Petr ask for
wishes for OpenTCM [1]. A tooling is needed, where you can integrate
L10N test cases, and general functionality test cases. And a tracking
of the results should be possible. In my view it isn't needed to run
all these test cases for each release/each language in the last weeks
of the release cycle. For general functionality tests it should be
enough, when one run the test case - because most feature are not
language depended. Translation is here a different part. Checking the
translation in new features, does not need test cases for functionality.
It is only needed to know, where the changes were done in UI.
I do not want to change processes in the L10N-teams. But I think, it
is a point which should be discussed in the L10N project and now we
have a QA Lead for this, Jaqueline Rahemipour.
Thorsten
[1] : http://qa.openoffice.org/servlets/ReadMsg?list=dev&msgNo=8636
Sample for test case specification can be found here :
http://qa.openoffice.org/ooQAReloaded/TestcaseSpecifications/OpenOffice.org_2.3/
sophie wrote:
Hi Thorsten,
Thorsten Ziehm wrote:
Hi Sophie,
what test cases do you mean?
Hum, not sure you read this thread ;) I mean TCM L10n like in the subject.
The general functionality of new features are tested before integration
of these features. You will find test case specifications or links to
automated test cases in the feature list for OOo2.3 [1]. So it isn't
needed to write new test cases.
Only to translate them if you want some feed back for non English
speaking communities. Ans some test case are not present in your list,
may be they are not needed ?
Currently the test cases in TCM are only for areas, where translated
strings change the functionality or where native speakers have to check
if the defaults for their languages are correct (e.g. date format).
Yes, and from what I know, their is 5287 new words in the GUI. My
question was: are the corresponding tests present in the TCM ? otherwise
why should we do TCM test case ?
Testing of general functionality isn't and shouldn't be part of TCM.
Here I think we need a new tooling, or we have to link complex test
cases in TCM.
Ha, I'm quite surprised as we are doing those tests for several releases
now.
What do you mean by new tooling ? If I want my team to test the FR
release, I need to upload the manual tests on TCM (like the one Validity
described following your link for example) to be able to track the
results on the plateform our group is testing on. Do you mean it is
useless and won't bring anything ?
So what do you mean with new test cases? Testing general functionality
or L10N related issues for the new feature?
I mean l10n QA, but I'm now puzzled by the fact that new
functionnalities shouldn't go on TCM. And I find it sometime very
difficult to separate the l10n part to the functionnality part in a bug.
Kind regards
Sophie
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
