If you are planning to localize your software, it is a good idea to test it once it has been translated. This will ensure that the translated terms are shown in the proper context linguistically. Additionally, testing software will make certain that it works properly in the target language and within the target locale and operating system. Generally speaking, testing is focused on solving localization-induced problems and seeks to ensure the localized software matches the source software in appearance, functionality, and compatibility.

Globalization testing can take many forms, some of which can even be done before translation is begun. This type of testing is called internationalization testing and is performed before localization to determine if software will work correctly in the target language. Here, the executable software is evaluated by checking correctness of user input in various character sets and verifying that the display of culturally specific information (like time or date formats) is linked to the operating system locale settings.

Once software is internationalized, it is ready to be translated. After the translation is completed, user-interface testing can begin. During user interface testing it is important to look for the following:

• incomplete translations
  
• truncated strings
  
• incorrect spelling and terminology
  
• duplicate or missing shortcut keys<
  
• inconsistencies in user interface layout

Often linguistic testing is performed in conjunction with user interface testing. While user interface testing looks mostly at UI layout and appearance, linguistic testing targets the correctness of the translation in context. Because user interface testing is technically focused, it can often be conducted by a non-native speaker. However, linguistic testing deals specifically with the accuracy of translation and therefore needs to be performed by a native speaker of the target language.

During the linguistic testing phase, a native speaker checks that:

• all text is translated and translation is grammatically and contextually correct
  
• accented characters display correctly
  
• all dialog boxes are properly resized and dialog boxes, status bar messages and menu items fit on the screen in all resolutions
  
• concatenated strings display correctly
  
• icons, graphics or sounds in the localized application are relevant to the target language market
  
• correct formats and locale settings have been used in the target language(e.g. date, time, number and currency formats, etc.)
  
• there are no inconsistencies in terminology between various locations in the software, and between the software and help

For some projects, testing is taken one step further to full functionality testing. For this type of testing, test scripts that you have created are used to test the original source-language software. Functionality testing ensures that the localized version functions correctly by actually examining the operation of the software against specific test cases provided to your localization vendor in the form of test scripts.

Functionality testing includes the following:

• comparing the functionality of the localized application against the source
  
• checking that all buttons are jumping to the correct screens and that the software functions exactly as the source
  
• ensuring that there is no clipping on text or dialogs in the application
  
• confirming the overall appearance matches the English software
  
• testing the install and uninstall of the localized product
  
• checking extended characters, long filenames and international date/time formats

The final type of testing is compatibility testing. This is where the software is tested on additional types of hardware, with different operating systems, or in various software environments. Localized software is always tested on target-language operating systems and with localized supporting applications. Because many strings are called from the operating system, it is important to use the localized OS versions to verify that no source-language text was missed in the localization effort and to ensure that character encoding and fonts interface correctly.

Once you have determined what sort of testing you require of your localization partner it is always a good idea to keep in mind the information you should provide when communicating about your localization project, including answers to the following questions:

1. What type of testing is required?
   
2. Are there test scripts available?
   
3. Where will the testing take place? On-site at your location, on-site at your localization vendor, or remotely through a staging server?
   
4. On what specific platforms should the application should be tested?
   
5. Is there any specific software or hardware needed for testing the application?
   
6. How long does a user interface test cycle typically take on the source software?

There may be several test passes carried out on the software until all bugs have been signed off by the testing team. Testing usually begins will a full product test pass. During this phase bugs are logged. A team of engineers and quality assurance specialists then fix and regress all tracked bugs and complete the process with a final product test pass.

Because every software application is different and requires a different testing approach, bug tracking also varies. Generally, 80% of bugs that are found while testing are linguistic bugs and the remaining 20% are functional bugs. This split may often result in what you see when you view your bug reports during testing. Since functional errors must usually be fixed by developers and require code changes, you will typically see these errors escalated to your attention in bug reports. Your should expect your localization partner to correct linguistic and user interface layout bugs.

It is crucial that you communicate openly with your localization vendor about testing expectations and procedures to ensure that your translated software operates properly upon its delivery.