Effective testing of localized hardware

Hewlett-Packard Journal, June, 1997 by Evangelos Nikolaropoulos, Jorg Schwering, Andreas Pirrung

Testing localized software is a complex and time-consuming task. With the help of the testing tools developed for HP patient monitors, local language validation for these products is fully automated.

Localization plays a very important role in the successful marketing of software all over the world. For medical devices there are legal requirements to provide instruments and accompanying documentation in the language of the healthcare personnel who use them (as is the case in the European Union). It is often forgotten that localized software is different software from the original (most probably in English) that was used for system integration and final validation. Localized software undergoes a proper integration cycle (integration of software and translated strings) and must be validated separately. The complexity of this validation is obvious if one considers the efforts required to check all error conditions and the corresponding error messages (and to understand them) for software in every language where the product is marketed.

The most common errors in localized software, assuming that the translation is done by a professional translator for this language and is correct, are:

* Missing strings (empty messages, parts of screen text missing, menu selection items missing)

* Strings with wrong attributes (maximum length exceeded--a possible crash cause) or strange characters filling up the remainder of a field

* Wrong strings (not reflecting the intentions of the author for this particular context)

* Various misspellings or violations of grammar rules applied to the language produced through the combination of translated strings by the software

* Strings not properly cleared in a text field before a new string is displayed.

Local language testing in our laboratory is composed of two steps: the verification of the translation and the validation (regression testing) of the localized software.

To verify the translation, a translator goes over all possible screens, messages, help texts, printouts, and so on to check for translation errors. The difficulty here is that in most cases the translator is not a frequent user of the device under test, and needs assistance in operating the medical instrument and generating all possible string combinations.

The aim of validation (regression testing) of the localized software is to prove that the localization has not negatively affected the functionality and performance of the instrument. Additional attention must be paid to typical localization errors (overflows or garbage generation).

Automated Local Language Validation

With the help of the testing tools developed for our patient monitors (see Fig. 1 and the accompanying articles in this issue), local language validation is a fully automated process:

[Figure 1 ILLUSTRATION OMITTED]

1. Translation tables called local language tables are prepared from the native language support database containing all the English strings and their corresponding translations.

2. A test package, a subset of the test procedures designed for the regression testing of the original English version, is compiled.

3. A copy of each test procedure out of this package is translated into the local language by a tool developed by software quality engineering called skey. The intention here is to replace in the test procedures the selection menu items (softkeys) with the corresponding localized terms. Of course, a test can be executed by passing the position of a selection item (e.g., "press the second selection on the third menu") to the test execution tool, but this approach has proved to be ineffective. The issue here is not to test that the "second selection of the third menu" works, because this was already tested in English, but to prove that the "second selection of the third menu" is translated correctly, and if selected, produces exactly the same behavior as its English counterpart. By calling the selections by their values and not by their positions we achieve higher test coverage and we test functionality and translation at the same time. Another argument for this approach is that the "second selection on the third menu" may be configuration dependent (even local configuration dependent) and therefore not accessible by a position dependent test (e.g., it is still on the third menu but in the sixth place). Thus, calls by value make test procedures more robust.

4. The translated test procedure is passed to AutoTest[1] and is run on the localized software. The results are saved in protocol files containing English verify statements (the expected results), localized softkeys (selections), and localized actual results (see the example in Fig. 2).

[Figure 2 ILLUSTRATION OMITTED]

5. The protocol files are submitted to AutoCheck (see article, page 103). First, the AutoCheck preprocessor takes over the task of translating the verify statements. It uses the local language tables to replace the English text in the verify clauses with the localized text. On the second pass these translated expected results are compared with the localized actual results. Discrepancies are reported in the normal way but with localized content.