Measurement and best practices of i18n and l10n testing (1)

To measure how well you are doing i18n and l10n testing, here are some of the metrics:



1. How many i18n bugs are found before and after l10n testing is
started. Ideally most of the i18n bugs should be found and resolved at
the same time with the other functional bugs, and very few i18n bugs
will be found when l10n testing is started. The later i18n bugs are
found, the more l10n rework might happen, and the less time to resolve
those i18n bugs and thus the worse the g11n quality the product will be.



2. How soon can i18n bugs or l10n bugs be resolved compared with non
i18n and l10n bugs. I18n and l10n bugs shouldn't take longer time to be
fixed than the other bugs.



3.  How many i18n test cases or suites are reused for l10n
testing? The best practice is to reuse all i18n test cases and suites
in l10n testing, the difference between i18n and l10n testing is the
messages will be pseudo l10n messages during i18n testing but will be
real translations in l10n testing.



4. What percent of i18n testing and l10n testing is automated, the more
automation in i18n testing, the more configurations/platforms can be
covered. The more automation in l10n testing, the more time can be
spent on manual checking of the translations in the context.



5. How much leverage among different languages, builds and platforms
during i18n testing and l10n testing, the best practice is define a
complete matrix to rotate among languages and platforms for different
builds.

Posted at 12:43PM Oct 26, 2006 by byuan in Globalization  |  Comments[0]