Quality assurance is the process of checking to see if the product or service is satisfying customer requirements. Localization QA should be the last step in verifying that the released localized product can accurately deliver its intended function to the end user. It is performed before committing to expensive production, duplication, or shipping costs to avoid having to remediate due to undetected errors. QA is not to be confused with the level of quality in each step of the localization process. Quality workmanship is part of every task:
- Properly defining the project requirements
- Preparing a complete localization kit.
- Accurately translating and correctly editing the text.
- Performing accurate dialog box resizing and professional desktop publishing.
It follows through right up to the release of the localized product, website, or document. Q A is best handled by in-country representatives, technical staff, or client beta sites. They can run your localized application, or review the localized website and documents. Involving expert users in providing constructive feedback to confirm the accuracy of the translation is very helpful to the localization team. End-user feedback can bridge quality and expectation gaps between users and the localization team.
In the absence of third-party QA, you may engage hired contractors to perform this step.The time needed for software localization QA is based on specific requirements, which vary widely. The project manager should work with engineering, localization, and the production teams to determine metrics for the work to be done. Knowing exactly how much time is to be spent on “QA’ing” the application itself helps define how much time will be required for each localized language.
In order to keep high standards it would be good practice to involve quality assurance also before and during the translation process: writing a quality plan and set particular milestone points to test. To ensure a good result, the translation project needs to be tracked constantly.
Translation quality is a combination of many factors:
- Having a good translation management system;
- Partnering with a good vendor;
- Having qualified linguists etc.
Making a general quality plan means:
- Evaluate the linguists and the industry standards the vendor is adhering to;
- Define the scope of the translation project;
- Provide examples of previous translations that meet the quality expectation (as well as common mistakes to avoid);
- Give all the information possible about the product, including brand guidelines;
- Define target audience and text type;
- Communicate regularly with the LSP (Language service provider) and make sure that anytime there is an issue there is a good corrective plan as well.
Quality translation can be very subjective, it is useful in this light to provide to the translators the necessary language style guides,terminology and comments on the context.
The final checks can be either automated or non-automated.
Most localization testing is manual as text needs to be read, layout needs to be checked and localization needs to be verified, all of which require a human to manually do it. However there are still cases in which automation can be used. For example:
- Web localization testing – Forms can be submitted using automation and links can be verified.
- Software localization testing – Functional validation can be performed via automation.
Also for cases where advanced knowledge of the software is necessary for testing, taking screenshots for review by localization testers may be a more efficient approach.
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.
Non-automated checks include:
- Linguistic testing
- Checks for offensive content
Software Localization: Software Product Testing Cycles[edit | edit source]
1. Internationalization Testing
Internationalization testing (testing an English product for localizability and international support).
- Performed on the English product during the development cycle.
- Verifies if the localized product supports all possible locales and scripts.
- Checks whether the product is easy to localize.
- Target language native speakers have to be involved in testing.
1.1 International Support Testing
International support testing focuses on the language support integrated in the application.
To be considered:
- Extended characters and text scripts support (especially multi-byte languages, like Japanese, Chinese and Korean).
- Text scripts output and display.
- Different regional settings support (date, time and currency formats, calendar standards, decimal separators, paper size standards, measurements, address and telephone formats).
- Different sorting methods support (such as Japanese phonetic sorting order).
- Localized versions of the operating system support.
- International hardware support (such as supporting local keyboard layouts).
1.2 Localizability Testing/Usability Testing
Localizability testing is required to verify if the application is easy to localize.
To be considered:
- Translatable components (have to be externalized from the source code).
- Regional settings (have to be hard-coded).
- Concatenations that may cause problems for translators.
- Text expansions (for dialog boxes and forms).
- Graphics, colors and other components that need to be adjusted for certain target locales.
- Bitmaps and icons with translatable text.
2. Localization Testing
Localization testing (reviewing the translated software in context).
- Performed on each language version of a localized software product.
- The localization vendor is usually involved.
- Requires test scripts.
- Focuses on linguistic and cosmetic verification of the localized application.
2.1 Linguistic Testing
- Linguistic verification of the running application.
- Ideally performed by the software translator that uses test scripts.
- Reviewing each and every dialog box, menu and as many strings as possible.
To be considered:
- Text display (has to be shown in the correct language).
- Spelling, grammar and syntax.
- Translation being appropriate to the context.
- Consistency in translation.
- The correct display of the strings with variables.
- The correct display of the accented characters.
- Text layout.
2.2 Cosmetic Testing (User Interface Testing)
Cosmetic testing focuses on all visual aspects of a localized application (menus, dialog boxes, messages, reports, etc.)
To be considered:
- The number of options, menus, or commands in the localized version (has to be the same as in the original one).
- Application aesthetics (sizing and alignment of buttons, control boxes, etc.).
- Dialog boxes (have to be able to be resized without truncations).
- Extended characters display.
- Menu items, help balloons, dialog boxes, status bar messages (have to fit on the screen in all resolutions).
- Regional settings in dialog boxes (decimal separators, date and time formats, etc. have to be correct).
3. Functionality Testing
Functionality testing (verifying that there is no damage to the functionality of the product because of the localization process).
- Focuses on the localized application functionality.
- Performed at a certain point in the test cycle (when the translation is finalized and stable).
- Usually mirrors the testing process performed on the source language product.
- Often includes a compatibility test (checking how compatible a product is with other products available in target languages).
To be considered:
- Mirroring (functionality and feature set of the localized application have to mirror that of the source language).
- Using international keyboards and keyboard layouts (ability to type accented text, use control keys and hot keys).
- Defaulting to the regional settings specified in the operating system.
- Copying and pasting strings from the localized application to another one.
- Ability to function correctly on a localized operating environment.
- Compatibility with locally developed products.
- Language-specific add-ons (such as spelling checkers) working correctly.
Often included in a functional testing cycle:
- Integration testing (several product components are tested together after they have been tested individually).
- Performance testing (stress testing, load testing).
- Regression testing (a new release of a product is re-tested; it is usually performed during the localization testing cycle).
- Acceptance testing (formal testing if the final product should be accepted).
Localization Testing – Software[edit | edit source]
There are specific challenges that software localization specialists experience during the localization process. Localized strings may cause layout and even functional issues during the software localization process. For example, romance languages take around 20% - 30% more space than EN-US. However, most of the layout issues are only identified on the testing level. Some strategies to avoid or fix layout issues include:
- Say it in other words! Localization specialists must making sure the main idea is conveyed but at the same time must avoid unnecessary/redundant information.
- Abbreviating words or phrases can be an option in some contexts. For example, names of the months or days of the week can be abbreviated when there is not enough space to display them in full. Another option would be using only digits: 12/31/2016 instead of December 31, 2016.
- In some cases, terminology can be changed in order to fit dedicated space for buttons or descriptive strings. This should be the least option for localization specialists to keep consistency. It should also be agreed with client and terminologist.
- Instead of using words, localization specialists may opt to use icons and images to convey the same message.
Localization testing – help content[edit | edit source]
Localization testing – games[edit | edit source]
Video games being marketed to different locales will undergo localization testing. Localization testers may then act as text editors. Their tasks include checking the accuracy and quality of the text, that the text is displayed correctly, as well as making sure that the content is appropriate for the specific locale and rating. Localization testers are also often expected to be fluent in both the source and target languages, ensuring that they will be able to adjust translations as needed.
Linguistic Quality Assurance (reviews, spot checks)[edit | edit source]
- Moore, Michael E.; Novak, Jeannie (2010). Game Industry Career Guide. Delmar: Cengage Learning. ISBN 978-1-4283-7647-2.
- Bethke, Erik (2003). Game Development and Production. ISBN 978-1-5562-2951-0.