Hi,
IMHO, use of testtool for release sanity check is time consuming.
The tool is, indeed, useful to find regression bugs at the stage of
development. It, however, in general, cannot find localization related
bugs since it is naturally language-neutral.
partly correct... see below.
For resource files *.res, which reside in the directory program/resource/,
are normally created regardless of existence of localized text since
if a desired localized text is missing, then a fallback text, normally
en_US, is automatically used as an alternative.
AFAIK this assumption is partly correct. If a translation is missing
then we have a fallback to en-US but if a resource file is broken then
the application crashes. In this case it's useful to check dialogs via
Cat-0 test which runs about eight hours.
Thus, there could be a situation where *.res files exist, but their texts
are not localized or are mistranslated. This type of situation cannot be
found by the testtool.
How can we find such a situation?
In this case I have no answer as it (AFAIK) is indeed not possible to
find such fallbacks by using the Testtool
IMHO, manually testing release candidates by native language specking
persons would be the most effective way for release sanity check of
localized
versions. Thus, Cor Nouws's conclusion is on the right truck, I guess.
Cor Nouws wrote:
> So I conclude it is OK to check;
> - installation;
> - some localized dialogs;
> - some autocorrect/autotext;
> - some help content;
> - language settings as time and separator.
Is there high possibility where one of or a few *.res files are physically
broken while most of *.res files are correctly created? If so, testtool
might be helpful.
Yes. I remember it already happened.
But, running testtool more than 24 hours for release sanity check does
not make sense, I think.
That's a good approach.
Kind regards, Joost
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
