Hi Vito,
I want to explain only one point :
> 1) replacing TCM use cases with scripts - oh h*l, why not?! I'd write
> the first few ("open a Word file and store it as a odt..."
Testing of TCM test cases has a different aspect on testing OOo. The
initial aspect was to check only L10N and localization related problems.
Most of these issues cannot be checked by a automated tooling and has to
be checked in best by a native speaker. Yes it is easy to open and save
a document, but it isn't possible to check if the characters are
displayed correctly. This has to be checked by a human person. And also
the TestTool doesn't initially if the default style of dates and times
are correct.
I do not know every test case in TCM, I have to admit. It is growing
by the L10N teams. So I leave the overview. But if there are tests,
which aren't related to localized or L10N specific problems, they can
be eliminated and should be integrated into an automated test - if
possible.
One one test should be there. A scenario for a sanity check without
any usage of a TestTool or something other automated tooling.
That's my view on testing TCM test cases.
Thorsten
Vito Smolej wrote:
Hi Jogi:
My shortlist:
1) replacing TCM use cases with scripts - oh h*l, why not?! I'd write
the first few ("open a Word file and store it as a odt..."
2) triangulate grey areas and fill them up - what else is there to be
tested
3) YA language generator - right now climbing up and down the tree
structure and finding places, where to put a string or two, is no fun
4) testtool lint aka "Who's testing testtools": how can one prove that
his/her current / next revision is OK? One needs to test/qc it for ...
- completeness
- consistency
- ,,,(see 3)
5) going beyond land codes (sort of linguistic Unicode to avoid the
two-digits bottleneck in the future)
6) user's interaction, in the simplest form as a message box "Look at
the document and press Yes if OK, and No if not" (see 1 above). Comment:
you probably had it and threw it out because it interferes with
automatic execution. But one could just as well swap this kind of
questions out of the way and have them checked later, when the procedure
has finished.
Regards
smo
Joerg Sievers wrote:
Hi!
It's nice to see that the interest on using the VCL TestTool is
growing. Thank you very much for your comments, suggestions etc. Be
sure, we read it and we answer! And we need your input!
The automated testing team inside Sun Microsystems maintains at the
moment 100% of the testing code but there is hope that also others
will start writing test code in future which can be also shared and
used by others. That would be a great test case development.
To get you into the boat we want to get a good set of test scripts [1]
and will do some enhancements in these areas:
1. Documentation
2. Reuse
3. Structured
4. Mainenance
We know for 1.) that we need to document how to add a new L10N
language to the framework and also we need to make it easier (4.).
_Do you_ have suggestions for the other areas we should think about?
If yes, feel free to write here an answer. We want to collect in the
next three weeks which enhancements we need to to do to get the
barriers down and you into the boat. I will summarize it and maybe you
are alos interested to do some work with us...
Thank you in advance for supporting OOo!
Cu,
Jogi
http://qa.openoffice.org/qatesttool
http://wiki.services.openoffice.org/wiki/User:Jsi
_____
[1] Software Test Automation, Mark Fewster & Dorothy Graham, Addison
Wesley, 1999, ISBN 0-201-33140-3, page 69; table 3.1 "Comparison
of good and poor sets of test scripts that perform the same set
of test cases"
---------------------------------------------------------------------
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]
