Quality assurance (QA) should form part of any software development project. It is a way to ensure a high standard of work and a satisfactory outcome. But QA plays a bigger role in localization projects than just bug bashing.
A very specific kind of review of the product needs to happen before it is shipped, to ensure the product is fit for purpose in its intended market.
The aim of any software localization project is to provide the same user experience for its new audience as it did for its original one. This isn’t as simple as merely translating the linguistic elements – although that is important too.
The localization team may also need to adapt the user interface and test elements such as forms and dialogues, particularly if you are adapting to a language that is orientated differently or likely to have longer content than the original language.
There may also need to be some technical localization, such as setting up a new build environment, which needs to be checked carefully.
There are two main components of your localized project that will need QA attention before it launches. The first is the accuracy of the language, looking at elements such as grammatical accuracy and consistency.
The second is the functionality itself. There are many reasons why the functionality needs to be re-evaluated when a product is localized, including the need to check whether any new bugs have been introduced into the software during the localization process.
How to QA a localized product
A good QA will evaluate the overall user experience for the newly-localized product, as well as perform the usual bug checks. They will generally use a combination of scripted and manual tests, as they would for any kind of project.
What’s different is that QAs will often use a specialized test approach called pseudo-localization to approach a project of this kind, right before it even begins.
Pseudo-localization is a way to preemptively assess the suitability of your software for localization and may help identify potential QA concerns in advance. This helps reveal many of the most obvious translation problems that may arise in the localized product on completion.
Localizing the user interface for an application can be quite challenging if the developer does not provide enough space for text expansion.
Some of the most common problems that are uncovered by pseudo-localization include the issue of test expansion. This occurs when translated content is longer than the original content and leads to problems such as menu items or button labels being too long for the design.
RELATED: How Product Development Teams Can Benefit from Continuous Localization
Pseudo-localization also helps ensure all character sets can be supported, which helps avoid ‘garbled’ characters appearing in the finished product.
Pseudo-localization can also identify hard-coded strings that may need to be changed to localized strings. This includes elements such as date and time or currency formatting, which should ideally not have been hard-coded into the build in the first place.
These strings should be localizable so that the code is more suited to adapting to new environments and markets.
Skills shortage
Unfortunately, like many areas of tech, good localization QA skills are in short supply. To properly evaluate a localized software project you need QA testers with local knowledge and understanding and the required language skills. These can be hard to find in combination with the necessary technical skills to properly assess the quality of the product.
Finding the right local talent will be essential if you wish to achieve excellent quality assurance during your localization projects.
Global organizations are best advised to leave the QA process to local teams. This can mean hiring local vendors or finding local associates, or using existing local teams if you have them.
RELATED: How to Work Successfully with International Vendors
They will hopefully be able to track down an appropriate team of users to evaluate the product in beta phase. They will need to assess both the accuracy and effectiveness of the translated software, as well as evaluate how it is likely to be received by end users.
One of the mistakes that brands often make is to insist on hiring QA teams with sector-specific knowledge and experience. It is more important to seek out QA professionals with technical knowledge and ability as well as local knowledge rather than the experience of your specific sector. It is more important that they understand user needs than that they understand your sector.
You can help your QAs by putting together a strong brief that helps them understand the users the project is aimed at.
It is helpful if your localization project has a very specific audience in mind. For instance, consider the audience you are targeting rather than just the language of translation. Countries can share a language but not share date formats or currencies – the US, UK, and Republic of Ireland are good examples of this. It helps to be specific.
Future proofing projects
In an ideal world, software projects would be built with later localization in mind. If you’re building an original product and plan to later localize it, you can help make the eventual localisation process go smoother by building with this in mind.
For example, you will aim to design a product that can accommodate more characters and with localized strings for items such as date, currency and time formats.
You will avoid hard-coding text and use separate resource files for things such as error messages. You can also help future-proof your project against later localization problems by building a library of internationalized objects such as search functionality and address formats.
It is usually not the case that projects are built with later localization in mind, the best mitigation for a lack of foresight is to test early and often in the project’s localization journey and to leave plenty of time to adequately manage the localization process.
Robust QA can make the difference between a winning product and a forgettable one. That’s why it is important to leave plenty of time for QA and testing in any localization project.
