What is localisation testing?
Localisation testing refers to quality assurance checks applied to localised versions of a software solution. Similar to other types of testing, there are both general QA techniques and localisation-specific issues to consider. This is a very collaborative activity, even if the definition doesnāt say so. You will need input from Product Owner, regional managers, and perhaps even the translators as well.
Best practices for localisation testing process go beyond translations. You need to verify whether your fonts support the new language. You should test for behaviour that does not happen in your language, e.g. rendering search suggestions from right to left in Hebrew. This is even more relevant when you need to muster a localisation implementation without a designer available.Ā
As a former translator, there is another localisation testing aspect that I find quite amusing. Even if you donāt plan to explore new markets any time soon, your application should be localisation-ready. Hard coding English texts into your app is a cardinal sin. Making designs that wonāt fit ālengthyā languages will bite you later (we know the feeling). Not containing common issues from a sloppy localisation implementation will slow down your hypothesis testing.
This article may border on the best practices for the localisation process itself, and for a good reason. Some costly mistakes come from a combination of subpar translation work and a lack of QA criticism that allowed the slip. It takes one to lose money, yet you need to nail both translation and testing to succeed. Unfair, isnāt it?
Microsoft is a popular punching bag for testing blunders, so why not have another go at it? In late 2018, they decided to switch online payments from local currency to US Dollar where possible. The move included Russia (1 USD=66 RUB at the time), so Microsoft started to gradually update prices for video games and Office licences. Gradually is exactly what cost them.
Users quickly discovered that you could convert the entire cart to rubles by adding one ruble-priced product to any number of USD-priced goods. You could buy 4 new video games (list price of $60 each) for ~$6 instead of $240, because the store erroneously made a 1:1 currency conversion and took it for granted. Missing a simple sanity check for the historical exchange rate would have cost Microsoft around $500,000 with the average daily sales volume in Russia. Alas, pricing errors usually bring a much higher number of transactions.Ā
Localisation vs Location vs Localised Testing
When it comes to software, the terms “localisation,” “location,” and “localised testing” might seem interchangeable, but they represent distinct processes. Here is how they differ:Ā
- Localisation testing validates software adaptation for a specific market or region, ensuring it aligns with cultural, linguistic, and functional requirements. Automated tools play a significant role in streamlining and accelerating the testing process, especially when aiming to automate localisation testing.
- Location testing checks software functionalities that depend on users’ or services’ physical positioning or geographic location.
- Localised testing involves scrutinising a software version adapted or translated for a specific market, ensuring accuracy and functionality within the context of the target audience’s language, culture, and preferences.
Understanding the nuances between these testing processes is pivotal for a comprehensive and effective software testing strategy tailored to specific markets, locations, and adapted software versions.
Elements of successful localisation testing
Thorough localisation QA means going through as many points of failure as possible. Here are some key ones:
- Automated language selection
- Intuitive language change flow
- Font compatibility
- Proper rendering of non-Roman characters
- Exhaustive text input options
- Form input compatibility
- Multi-language input support
Good localisation testing also involves good planning. You will need a solid testing strategy to cover the most QA ground in the least amount of time possible. We are happy to share a strategy that we use to both test our software and help consulting clients do that.
Testing strategy to make your localisation testing 2 times faster
Checking for localisation testing
Effective localisation testing checklist involves meticulous attention to various crucial aspects of a software’s adaptation to a specific market.Ā
- Cultural Adaptation: Beyond language, it’s essential to ensure that the software aligns with the cultural norms and practices of the target audience. This includes imagery, symbols, and even the concept of colours, which may have different connotations in various cultures.Ā
- Functional Validation: Testing the software’s functionality in the context of the localised version is crucial. Features, buttons, and functionalities need to work and look seamlessly within the context of the adapted language and settings.Ā
- UI/UX Adaptation: User interface and experience elements must be checked for consistency and adaptability. The layout, design, and usability should resonate with the targeted region.Ā
- Technical Aspects: Beyond the visible elements, aspects like font compatibility, proper rendering of non-Roman characters, and handling various text inputs need thorough monitoring.
A complete examination of cultural, functional, UI/UX, and technical elements within localisation testing is fundamental to ensure robust localisation quality assurance.
5 best practices for localisation testing
Localisation testing best practices can vary depending on your project, geographical ambitions, and the difference between source and target languages. The suggestions below, however, should fit you in most projects.Ā
Keep localisation organised
I touched upon this at the beginning, and I will do it again. Localisation should be a software-level effort driven by the product and business teams, not an afterthought. If a quick implementation from developers does not give that feel, it is time for QA to push back.
For coding, the biggest flaw could be how languages are handled internally. Without a proper string-for-string structure, it is easy for devs to forget to replace a piece of text. A non-visual editor for translated texts can break text rendering without the content people even spotting it. An internationally scalable product needs a scalable localisation solution.
On the content side, you mostly need to have a source of truth and possibly a revision history. Computer-assisted translation tools (CAT) cover both, and you will usually need little effort to make them fit your project. A good translation database means QA will always know what is right and wrong.
You should also get source material in advance for a proper localisation, especially for simultaneous launches. Here is how Scott Strichart, a localisation producer at SEGA, explained the misaligned lip sync for the English dub of their recent video game set in Japan:
āYouāve probably noticed that the lip sync in Lost Judgement is not as silky as Yakuza: Like a Dragonās was, and it wonāt be. The short answer is simultaneous shipping.
Like a Dragon finished recording ~9 months out from launch, and the lip adjustments were a post production process. You canāt do that before the actors say the words, obviously. Lost Judgement finished recording 4 months before launch. We were not going to decouple from the Japanese launch, [because] this simultaneous shipping is so important to Sega.ā
Set priorities
Entering a new market does not happen overnight, so your localisation testing coverage does not need to be perfect either. It will be okay to have some text rendering issues or even fall back to the source language where an implementation issue is not easy to fix.
The key word here is some. Key user journeys should always look impeccable before a business transaction is complete or transferred elsewhere. All the legal texts should display properly so your lawyers do not end up fighting a snapshot of a flawed T&C page in court. Helper texts in less popular features can wait.
Get stakeholders and colleagues involved
There will inevitably be design and information architecture constraints when translating texts into a new language. It would be irresponsible to not make texts look serviceable, but do you always know the least hurtful compromises?
When in doubt, always ask your coworkers to give you advice. Would English speakers be as upset and confused if you omitted some articles as German speakers would? Can you afford to break the convention and replace text numerals with digits? Ask before you do.
Design constraints have different impacts depending on the business intent, too. It will be harder to extend the onboarding carousel by another page if the steps do not fit vertically. But what if you need to do the same in the desktop version of your solution? And if yes, would conversions drop too hard if you do add another page on mobile? These questions are for QA to ask, but hardly them to answer.
Invite local end-users
Your users will not really be assessing your localisation on a scale. The goal is to make them focus on the app rather than be jarred by localisation quirks. There are certainly quirks that you will not spot as a foreigner.
This point goes beyond texts as well. Imagine your designer pictures a desired flow as a car ride along a public road. They may get really cheesy and put the login form into the front passenger seat of a ācarā on the web page. Sounds eclectic enough, doesnāt it? It gets outright confusing if you show Japanese users a car with the steering wheel on the left. Did you know that FaceTiming a sales lead is not really a thing in UAE because FaceTime does not work on phones purchased there?
Savvy end-users can help you with more than just cultural context, too. They may see UI patterns that are not characteristic of the region. Your product and business team can then see if they would prefer to fall in line or bring something new.
Unleash automation
Localisation testing is repetitive and requires a consistent attention span that fits machines better than humans. Eliminating human error is well worth the time exploring how to automate localisation testing.Ā
There are two primary angles that you could choose or combine. UI testing is a major component of localisation testing, and there are a few AI-based options to choose from. Using these tools will save you plenty of time on both executing tests and adjusting them to UI changes.
You can also get test management software that helps you scale localisation tests. Here, AI-powered tools can help you create relevant tests or widen the coverage as you add more localised screens.Ā
Checklist for localisation testing
If you just scrolled down to the end, here is a checklist based on key localisation testing hurdles.
- Learn the scope
- Formalise localisation approach
- Explore automation
- Set priorities
- Involve stakeholders
- Keep translators close
- Double-check with end-users
Conclusion
Localisation testing may not get you a revenue surge, but you will surely notice potential losses. Good localisation testing is a culmination of proper localisation efforts verified by software quality assurance techniques. Test automation helps a lot to cut down on routine.
AI test automation is a great aid to reach the localisation precision to enter competitive markets. aquaās AI Copilot can make new localisation tests from scratch or complete your drafts. This is perfect for when you follow our advice and involve non-tech people, but they canāt make proper test cases. Our GPT-based solution will bridge the gap in no time.
Use AI in your localisation testing so you donāt sound robotic
