How to Plan a Software Localization Testing Strategy

Judy_chenBased at the Welocalize office in Beijing, China, Judy Chen is one of Welocalize’s senior localization managers. In this blog, Judy outlines the key steps to developing a software localization testing strategy.

We fully understand that software testing is very important step during the whole localization process. Localization testing is testing of localized products and capturing defects which are introduced while localizing a product: identifying and reporting issues, which can be fixed by localization software engineers.

A good testing strategy can help software providers to quickly release local versions of their software products and applications, supporting them to occupy and grow local markets successfully.

Based on different software developing models, there are different focuses when you want to localize into multiple target languages.

How do you plan an excellent testing strategy which exactly aligns its purposes with the client’s real needs and expectations?

First, we need identify the test scope. What is our main focus? What are the target languages? Which platform required? What aspects should not be included? For example, for software performance testing, stress testing should not be included into localization testing scope.

When we develop a testing strategy for a specific software product, we cover the following areas: Testing Scope, Test Case Development, Testing Execution Arrangement, Test Cases and Defect Management.

Testing Scope

Testing scope includes identifying the languages, testing platforms and test case coverage, the scope of new and specific features and components.

Test Case Development

Test case development is based on the scope of new and specific features and components and which are available and required for localization quality assurance (QA) to validate. Test case development should cover below aspects:

  • Verification of installer and uninstaller process
  • Verifying the user interface (UI) problems caused by localization, such as missing, untranslated, or mistranslated text, broken, duplicate or missing hot keys, text truncation, incorrect and missing icons and so on
  • Verifying functional issues caused by localization
  • Verification of the consistency of localization of all documentation, online help, multimedia, interface resources, command-key sequences and others
  • Verification of adherence to system, input and display environment standards
  • Checking for some internationalization (I18n) elements, such as:
    • Support multiple character types
    • Support appropriate fonts
    • Support reading and writing of external files
    • Render text correctly (GUI)
    • Display data appropriate in GUI

Testing Execution Arrangement

For a typical localization testing, we set up build verification testing, normal testing, regression testing and final sign-off.

  1. Build verification testing is a small subset of functional testing which is executed before QA starts with any detailed testing.
  2. Normal testing is the step to run the normal test cases and find log defects during execution.
  3. Regression testing is defect regression process to ensure the defect is fixed while there is no impact of fixed defects to surrounding areas.
  4. Final Sign-off is to perform final checking on the build before delivery to the client.

It is not unusual to run these test processes more than once, depending on different requirements and software products.

Test Cases and Defect Management

Test cases should be well maintained on a centralized management platform for easy management and recording of all test results.

Defects can be categorized as localization bugs or global and core bugs. Localization bugs are those bugs produced during localization process and should be fixed during the localization process. Global and core bugs are those bugs which can be reproduced on multiple target language versions, indicating the possibility of coding error in the source which might affect localization process and should be fixed by the client’s software development team.

Localization bugs should be recorded in the defect tracking system and communicated by localization engineers. Core and global bugs should be recorded in the defect tracking system to be communicated by client development team.

Additional Testing Solutions: Automation Testing

For some software localization projects, we also consider automation testing solutions. Although automation testing solutions may not be feasible for all software localization projects, for some big software localization projects which have huge repeat testing requests, automation testing may be good solution for long-term cost saving considerations. This method is typically used in projects which have lots of legacy features and functions and where there are high volumes of screen capturing workload for each release. Automation testing is commonly used for the screen shooting, UI testing and functional testing, which can all be adopted to both web testing and normal software testing.

Here are the main steps within a typical automation testing strategy:

  • Choose suitable automation testing tools
  • Distribute a workable automation testing framework
  • Obtain a feature scope which include test cases’ steps: typically from the manual testing team
  • Transfer the steps to executable scripts
  • Execute the scripts and collect the results
  • Analyze the results and report defects

During the testing period, automation testing should work together with manual testing, to ensure no coverage is missed. Automation testing is an additional testing solution but if it can be used smartly, the testing efficiency will improve dramatically.

If you want to find out more about Welocalize’s testing services, then take a look at our Welocalize QA and Testing Overview.