Quality assurance (QA) should form part of any software development project. It’s a way to ensure a high standard of work and ensure a satisfactory outcome. But QA plays a bigger role in localisation 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 localisation 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’s important too.
The localisation team may also need to adapt the user interface and test elements such as forms and dialogues, particularly if you’re adapting to a language that’s orientated differently or likely to have longer content than the original language.
There may also need to be some technical localisation, such as setting up a new build environment, which needs to be checked carefully.
There are two main components of your localised 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 localised, including the need to check whether any new bugs have been introduced into the software during the localization process.
How to QA a localised product
A good QA will evaluate the overall user experience for the newly-localised product, as well as perform the usual bug checks. They’ll 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 specialised test approach called pseudo-localisation to approach a project of this kind, right before it even begins.
Pseudo-localisation is a way to pre-emptively assess the suitability of your software for localisation and may help identify potential QA concerns in advance. This helps reveal many of the most obvious translation problems that may arise in the localised product on completion.
Localising 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-localisation 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 Localisation
Pseudo-localisation also helps ensure all character sets can be supported, which helps avoid ‘garbled’ characters appearing in the finished product.
Pseudo-localisation can also identify hard-coded strings that may need to be changed to localised 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 localisable so that the code is more suited to adapting to new environments and markets.
Skills shortage
Unfortunately, like many areas of tech, good localisation QA skills are in short supply. To properly evaluate a localised 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 localisation projects.
Global organisations 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’ll hopefully be able to track down an appropriate team of users to evaluate the product in beta phase. They’ll need to assess both the accuracy and effectiveness of the translated software, as well as evaluate how it’s 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’s 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’s 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’s helpful if your localisation project has a very specific audience in mind. For instance, consider the locale you’re 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 localisation in mind. If you’re building an original product and plan to later localise it, you can help make the eventual localisation process go smoother by building with this in mind.
For example, you’ll aim to design a product that can accommodate more characters and with localised strings for items such as date, currency and time formats.
You’ll avoid hardcoding text and use separate resource files for things such as error messages. You can also help future-proof your project against later localisation problems by building a library of internationalised objects such as search functionality and address formats.
As it usually isn’t the case that projects are built with later localisation in mind, the best mitigation for a lack of foresight is to test early and often in the project’s localisation journey and to leave plenty of time to adequately manage the localisation process.
Robust QA can make the difference between a winning product and a forgettable one. That’s why it’s important to leave plenty of time for QA and testing in any localization project.