Localisation testing is paramount for ensuring a seamless user experience for your international customers, enhancing revenues and driving new commerce from across the globe
In essence, localisation testing is ensuring that your software application appeals to a global market by adapting its regional settings, local parameters, images and languages, while still remaining personal to the end users’ cultures, customs and habits. Having localised content creates a bond between end user and application; making them more accepting and combining it with a user-friendly UI makes their experience a pleasant one.
You may well have come across the following acronyms, L18N and L10N. These basically refer to internationalisation and localisation respectively; in my experience these go hand-in-hand with one another and sometimes it is difficult to distinguish between them.
Further down in this article I will list a few pointers which should be considered when transforming your software to adapt to the local region, but first let me briefly explain L18N and L10N and you will see that if you want to localise your software they need to be done in unison.
Let’s begin with internationalisation. You should think of this as a prerequisite for localisation to occur. This is where the developers build the software as generic as possible so that when the need arises, it is flexible enough to be adapted for a specific locale. For example, a developer won’t restrict the number of characters allowed in an ID text box and will keep it open to allow for alpha-numeric characters.
On the other hand, the process of localisation is making the software understandable to the end user within a certain locale by translating all the text and using relevant colours and graphics that correlate to that particular culture and region.
You could almost think of L18N as the back end and L10N as the front end. I will loosely use the term localisation from this point forward which encompasses L18N and L10N.
When to conduct localisation testing
I strongly believe the localisation thought process should begin at the very start of the project during the design phase – if the team is aware that this project will be used in different regions the system needs to be flexible from the outset.
For example, when designing the database and front-end – if the team haven’t considered the software’s usage in different countries, limitations would have been applied to certain fields such as telephone numbers, ID numbers, currency fields etc. To fix this ‘bug’ once reaching the quality assurance stage will have a higher cost factor involved as well as impacting on project deadlines. Any fix would have to be tested to see if it now allows for global input, testing system-generated reports and PDF’s to ensure that changes have really propagated all the way through.
A few things to consider
These may seem like very trivial points in relation to localisation testing but they do have an impact further down the line which, apart from frustrating end users, could lead to revenue loss. Let’s assume a piece of software works 100% from a functional standpoint but has typographical and grammatical errors that an end-user experiences before getting to interact with the software; would they trust it? I know I wouldn’t!
If such obvious errors haven’t been spotted and fixed, imagine how many other errors could exist throughout the software?
Based on my experiences I have jotted down some important points that should be considered by teams to help tune their minds to localisation testing. This is by no means an exhaustive list, but should prove sufficient to assist software teams going forward.
Text structure & encoding
Upon designing the software keep in mind that you may have to cater for languages that read right-to-left as well as vertical characters. As a safe option it would be best to use UTF-8 encoding standards as it’s almost guaranteed to work across most browsers, with the least amount of errors/crashes.
Text boxes & text areas
Consider the character limitations before applying them, this will be very frustrating for the end-user and I’m sure most of us have experienced this at some point, for example when typing out an address and the character limit is reached.
This is a common one and could even boil down to preference instead of purely being governed by the regions in which the software is deployed. Whatever the case, it is important to keep the formatting consistent throughout the entire application, as well as on any reports, SMS, emails or letters which are generated via the application. NB: don’t forget to take into consideration the public holidays for that local market, you don’t want your customers losing revenue over this.
Bear in mind that when the application gets converted to the local language within a particular region, some words, which are short in English, can double in size once converted. If your dropdown lists do not scale, half the word or sentence can be cut-off. Most booking sites make strong use of dropdown lists and if a user is unable to read or see an option properly, revenue loss occurs as users abandon the booking process.
It took me some time to fully understand this, but colours do play a very, very important role in your application. This can actually go even further than just country or region; a particular culture within a country can have certain feelings towards a colour based on their belief system. Humans are visual creatures, so be cognisant of your colour choices so as not to offend anyone. I usually select a softer, natural colour palette, instead of something like primary reds/greens etc., to be on the safe side.
Ensure that currency symbols reflect accordingly. This is by far the most obvious issue that everyone thinks of when discussing localisation, however what’s overlooked is adopting the correct decimal point used in that region. If not catered for, this can lead to a nasty error or crash being displayed.
Legal, T&Cs, Help
These can be easily missed, yet are extremely important and possibly out of this list may be the most costly and specialised of the lot. You will need to verify layouts, spelling and most importantly, grammar. Every sentence needs to make perfect sense and be legally accurate.
Approach to localisation testing
As established above there are many factors to consider when conducting localisation testing, with some being highly specialised and some just very basic checks. In my experience, I have found that creating the test cases in a generic manner and then copying them across into each language test suite saves time initially and guarantees you consistency across each language test, however there will be a maintenance overhead.
Below is an example that I use and has worked for me, perhaps it could point your team in the right direction and serve as a basis for your test suite and/or can be improved on?
Is localisation testing important?
In short, yes. As we have established above, we are in a technologically driven world and some may even say a world without borders where, from the comfort of our own homes, we are able to order an item from the other side of the globe without having to worry about the language, currency, tax, or time zone implications.
As an end user we ‘trust’ that all the working mechanisms and logistics will function as expected and the software we are using will be clear, easy to relate to, and simple enough to allow for this. Far too often as testers we focus most of our attention on functionality, but equally important is usability and I believe we need to dedicate sufficient time towards testing this, coupled with localisation, to give the end-user as seamless a system as possible.
After all, as testers it is our mandate to have the system work effortlessly and to make end-users’ lives easier and more productive. I’ve barely scratched the surface with the amount of depth we could go into with this topic, but hopefully it’s enough, so that on your next project, you will have a better understanding of what to look out for.
XET Group South Africa