Software Testing

FOREIGN LANGUAGE
TESTING
CONTENTS
I. Making the Words and Pictures make Sense
II. Translation Issues:
1. Text Expansion
2. ASCII, DBCS and Unicode
3. Hot Keys and Shortcuts
4. Extended Characters
5. Computation on Characters
6. Reading Left to Right and Right to Left
7. Text on Graphics
8. Keeping the Text Out of the Code
III. Localization Issues:
1. Content Formats
2. Data Formats
IV. Configuration and Compatibility Issues:
1. Foreign Platform Configuration
2. Data Compatibility
V. How much Should You Test?

Anuradha Bhatia
Software Testing

I. Making the Words and Pictures make Sense

1. For the user who is not comfortable with the language the software is
developed, and the translation is not clear, pictures given in the catalogue
should be self-explanatory.
2. A poor translation, and it’s what software can look like to a non-English speaker
if little effort is put into building the software for foreign languages.
3. It’s easy to individually convert all the words, but to make the overall
instructions meaningful and useful requires much more work and attention.
4. Good translators have to be assigned the job as he is fluent in both languages;
can make the foreign text read as well as the original.
II. Translation Issues:
(Question: Explain the translation issues related to foreign language programming
= 8 marks)

1. Translation is just a part of the overall localization effort.

2. The testers team will need group of persons semi-fluent in the language testing,
is being able to navigate the software, read any text it displays, and type the
necessary commands to run your tests.

1. Text Expansion
1. The most straightforward example of a translation problem that can occur is
due to text expansion.
2. Although English may appear at times to be wordy, it turns out that when
English is translated into other languages, more characters are usually
necessary to say the same thing. Figure 1 shows how the size of a button needs
to expand to hold the translated.

Figure 1
2. ASCII, DBCS and Unicode
1. ASCII can represent only 256 different characters—not nearly enough to
represent all the possible characters in all languages.
2. When software started being developed for different languages, solutions
needed to be found to overcome this limitation.

Anuradha Bhatia
Software Testing

3. A code page is a replacement ASCII table, with a different code page for each
language.
4. If your software runs in Quebec on a French PC, it could load and use a code
page that supports French characters.
5. Russian uses a different code page for its Cyrillic characters.

Figure 2

3. Hot Keys and Shortcuts

1. In English, it’s Search. In French, it’s Réchercher.
2. If the hotkey for selecting Search in the English version of your software is
Alt+S, that will need to change in the French version.
3. In localized versions of your software, need to test that all the hotkeys and
shortcuts work properly and aren’t too difficult to use—for example, requiring a
third key-press.
4. While checking, make sure that the English hotkeys and shortcuts are disabled.

4. Extended Characters
1. A common problem with localized software, and even non-localized software, is
in its handling of extended characters.
2. Referring back to that ancient ASCII table, extended characters are the ones that
are outside the normal English alphabet of A–Z and a–z. Examples of these
would be the accented characters such as the éinJoséor the ñinEl Niño.
3. If software is properly written to use Unicode or even if it correctly manages
code pages or DBCS, this shouldn’t be an issue, but a tester should never assume
anything, so it’s worthwhile to check.

5. Computation on Characters
1. Related to extended characters are problems with how they’re interpreted by
software that performs calculations on them.
2. Two examples of this are word sorting and upper- and lowercase conversion.

Anuradha Bhatia
Software Testing

3. The other area where calculation on extended characters breaks down is with
upper- and lowercase conversion.
4. It’s a problem because the “trick” solution that many programmers learn in
school is to simply add or subtract 32 to the ASCII value of the letter to convert
it between cases.
5. Add 32 to the ASCII value of A and you get the ASCII value of a.
6. Unfortunately, that doesn’t work for extended characters. If you tried this
technique using the Apple Mac extended character set, you’d convert Ñ(ASCII
132) to § (ASCII 164) instead of ñ(ASCII 150)—not exactly what you’d expect.

6. Reading Left to Right and Right to Left

1. A huge issue for translation is that some languages, such as Hebrew and Arabic,
read from right to left, not left to right.
2. Imagine flipping your entire user interface into a mirror image of itself.
3. Major operating systems provide built-in support for handling these languages.
4. It requires a great deal of programming to make use of the OS’s features to do
the job.
5. From a testing standpoint, it’s probably safe to consider it a completely new
product, not just localization.

7. Text on Graphics
1. The English letters B, I, U, and A, they mean nothing to someone from Japan who
doesn’t read English. They might pick up on the meaning based on their look—
the Bis a bit dark, the Iis leaning, and the Uhas a line under it—but software isn’t
supposed to be a puzzle.
2. The impact of this is that when the software is localized, each icon will have to
be changed to reflect the new languages.
3. If there were many of these icons, it could get prohibitively expensive to localize
the program.
4. Look for text-in-graphic bugs early in the development cycle so they don’t make
it through to the end.

8. Keeping the Text out of the Code

1. The final translation problem to cover is white-box testing issue keep the text
out of the code.
2. All text strings, error messages, and really anything that could possibly be
translated should be stored in a separate file independent of the source code.
3. Never see a line of code such as another variation of this problem is when the
code dynamically generates a text message.
4. It might piece together snippets of text to create a larger message.
5. The code could take three strings: “You pressed the”, a variable string
containing the name of the key just pressed, “key just in time!”

Anuradha Bhatia
Software Testing

III. Localization Issues:

(Question: Explain the localization issues related to foreign language
programming = 8 marks)

1. Content Formats

Figure 3

1. In the United States, a soccer ball isn’t the same thing as a football! You don’t
drive on the left!
2. These may not seem right to you, but in other countries they would be perfectly
accurate.
3. If you’re testing a product that will be localized, need to carefully examine the
content to make sure it’s appropriate to the area where it will be used.
4. Content is all the other “stuff” besides the code that goes into the product.
5. Think about what other items in your software might be problematic if it was
sent to another country.

2. Data Formats
1. Different locales use different formats for data units such as currency, time, and
measurement.
2. Just as with content, these are localization, not translation, issues. A U.S. English
publishing program that works with inches couldn’t simply undergo a text
translation to use centimeters.
3. It would require code changes to alter the underlying formulas, gridlines, and so
on.

Anuradha Bhatia
Software Testing

Figure 4

IV. Configuration and Compatibility Issues:

(Question: Explain the configuration and the compatibility issue in foreign
language testing = 8 marks)

1. The problems that can crop up when software interacts with different hardware
and software are amplified by all the new and different combinations.
2. Performing this testing isn’t necessarily more difficult, just a bit larger of a task.
3. It can also tax your logistical skills to locate and acquire the foreign version of
hardware and software to test with.

1. Foreign Platform Configuration

1. Windows 98 supports 73 different languages and 66 different keyboards. It does
this, as shown in Figure 5, 6, 7, through the Keyboard Properties dialog via
Control Panel.
2. The drop-down list for languages runs from Afrikaans to Ukrainian and includes
eight different versions of English other than U.S. English (Australian, British,
Canadian, Caribbean, Irish, Jamaican, New Zealand, and South African), five
different German dialects, and 20 different Spanish dialects.
3. Keyboards are probably the piece of hardware with the largest language
dependencies, but depending on what you’re testing, there can be many others.
Printers, for example, would need to print all the characters your software
sends to them and properly format the output on the various paper sizes used in
different countries.
4. Software uses a modem, there might be issues related to the phone lines or
communication protocol differences.
5. Basically, any peripheral that your software could potentially work with needs
to be considered for a place in your equivalence partitions for platform
configuration and compatibility testing.

Anuradha Bhatia
Software Testing

Figure 5- Arabic keyboard

Figure 6- French keyboard

Figure 7- Russian keyboard

2. Data Compatibility
1. Just as with platform configuration testing, compatibility testing of data takes on
a whole new meaning when you add localization to the equation. Figure 10.8
shows how complex it can get moving data from one application to another.
2. In this example, a German application that uses metric units and extended
characters can move data to a different French program by saving and loading
to disk or using cut and paste.
3. That French application can then export the data for import to yet another
English application.
Anuradha Bhatia
Software Testing

4. That English program, which uses English units and non-extended characters,
can then move it all back to original German program.

Figure 8

V. How much Should You Test?

1. The big uncertainty that looms over localization testing is in determining how
much of the software you should test.
2. If you spent six months testing the U.S. English version, should you spend six
months testing a version localized into French?
3. Should you spend even more because of additional configuration and
compatibility issues?
4. This complex issue comes down to two questions: Was the project intended to
be localized from the very beginning?
5. Was programming code changed to make the localized version?
6. The localization issues to be tested in the beginning only.
7. The developer should be informed about the local use of the software.

Anuradha Bhatia