Site Archive (Complete)
Testing & Debugging Blog: You Are Not Done Yet: International Sufficiency
Testing and Debugging
BREAKPOINTS

Test, Debug, Release, Rinse, Repeat ...

by Kevin Carlson
THE BOOK OF TESTING

Thoughts From a Braidy Tester

by Michael Hunter
September 29, 2006

You Are Not Done Yet: International Sufficiency

You are not done testing yet unless...you have vetted your application's readiness for use in international locales. Even if you are positive that your application will never be used anywhere other than your own country, these issues are worth at least investigating. Your team may decide not to fix problems you find, but at least y'all will know where they are. And, really, are you one hundred percent certain that someone from upper Elbonia *won't* want to use your product?

  • Look for culture-specific images and terminology. For example, the color red is synonymous with danger in many Western cultures, but it symbolizes happiness or good luck in others.
  • Look for geo-political sensitivity issues. One common example is maps that cover areas whose ownership or exact boundaries are disputed between countries. If your application contains or displays maps in any fashion, be prepared for all kinds of pain the moment anyone outside your country starts using them!
  • Verify that your application correctly handles switching to different system locales, language packs, and code pages, both before your application has started and while it is running.
  • Verify that your application correctly handles switching to different regional settings, both before your application has started and while it is running: date and time formats, currency symbols and formats, and sort orders, to name just a few. Some or all of these settings will vary across locales and language packs; most modern operating systems allow you to customize all of this separately from changing languages or locales as well. (On Microsoft Windows, do this via the Regional Settings control panel applet.) For example, if your application works with currency, see what happens when you change your currency symbol to "abc". One application I worked on did not like this at all!
  • Verify that your application correctly handles multi-byte (e.g., Japanese), complex script (e.g., Arabic) and right-to-left (e.g., Hebrew) languages. Can you cursor around this text correctly? What happens if you mix right-to-left and left-to-right text?
  • Verify that all controls correctly interact with Input Method Editors (IMEs). This is especially important if you intend to sell into East Asian countries.
  • Verify that your application correctly handles different keyboard mappings. As with regional settings, certain locales and language packs will apply special keyboard mappings, but operating systems usually allow you to directly modify your keyboard map as well.
  • Verify your application correctly handles ANSI, multi-byte, and Unicode text, extended characters, and non-standard characters on input, display, edit, and output.
  • Verify that the correct sorting order is used. Sorting correctly is hard! Just ask anyone who has run into the infamous Turkish "i" sort order bug. If you rely on operating system-provided sort routines then you should be in good shape, but if your application does any custom sorting it probably does it wrong.
  • Verify that the system, user, and invariant locales are used as appropriate: use the user locale when displaying data to the user; use the system locale when working with non-Unicode strings, and use the invariant locale when formatting data for storage.
  • Verify that any language-dependent features work correctly.
  • Verify that your test cases correctly take into account all of these issues. In my experience, testers make all the same mistakes in this area as do developers - and won't you be embarrassed if your developer logs a bug against your test case! <g/>

Posted by The Braidy Tester at 07:30 AM  Permalink




 

♦ sponsored
INFO-LINK


Related Sites: DotNetJunkies, SD Expo, SqlJunkies