What is localization testing (LQA) and why is it important?

Neglecting localization testing (LQA — Localization Quality Assurance) is always tempting — why spend time on additional checks when everything is probably fine? In this article by Inlingo, we tell you why the LQA step is critical, how it impacts the final product, and how to prepare for testing to make it as effective as possible.

What is localization testing? 

LQA assesses the quality of localization, which helps find bugs before players do. It can be divided into two major groups: linguistic and cosmetic testing.

Linguistic testing is a general check of the text. First and foremost, it’s important to make sure there are no semantic, stylistic, factual, or other errors. In this stage, the translation is also checked for how natural or native it feels and how appropriate it is to the game itself. For instance, it’s important to make sure that “championship cup” wasn’t mistranslated as just “cup,” or a harmless decorative bow as “bow and arrow.” Such mistakes are quite common when the translator lacks context in the translation process, i.e. doesn’t have access to item images or descriptions while working.

Cosmetic testing assesses how harmoniously the text is integrated into the game. It checks line breaks, the placement of text on textures, font uniformity, and text displays in dialog windows. It’s important for cosmetic testing to not only reveal errors but also suggest an appropriate solution. For example, using a shortened version of interface text or a font that supports diacritical marks.

Linguistic and cosmetic testing improve the quality of the final product. A game’s localization should be unnoticeable, but it becomes obvious as soon as the first problems appear. Such problems can ruin a game’s chances to enter the global market, so spending extra time checking a game’s text and appearance is absolutely critical.

Performing LQA is also important because it increases a game’s chances of becoming featured or recommended in Google Play or the App Store. With a little luck, you’ll be able to exponentially increase the number of downloads. Now that’s a persuasive argument.

What materials do you need for testing?

Game testers should at least have access to the game build to perform testing. In theory that should be enough, but ideally developers also send additional materials to increase the effectiveness of LQA. Here is a general list of materials that help testers fully evaluate a game.

The build

Ideally, the build should include cheats or provide in-game currency. That way testers can fully concentrate on the task and cover a large volume of game material in minimal time.

Checklist or test plan

A list of things that need to be checked. For example:

• interface
• dialogs
• storyline
• item collections
• missions

Lockit or file with game texts

This is necessary to compare revealed discrepancies against other texts in the game.

At the end of testing, final corrections are made to the lockit.

Below is the sample checklist that we find most comfortable to work with. It describes which areas in the game look good and where testers discovered bugs.

Part of a lockit is also provided below. It was assembled in Google Sheets, but you can make the same kind of table in Excel, Strings, or any other format.

Some developers send screenshots from the game or video of gameplay to be checked. This significantly reduces time required for LQA, but it can be quite labor-intensive for the client, as taking lots of screenshots can be very time-consuming.

Who performs testing?

Usually experienced specialists with extensive industry knowledge perform LQA. They should be more than just dedicated gamers – they also need to understand linguistics and know the features and nuances of the language. There are two options here: testing by a native or non-native speaker.

LQA by a native speaker has the following advantages, but it isn’t cheap: 

Our recommendation is to have native speakers check everything. Your choice depends on your budget, of course, but being stingy on testing isn’t worth it.

What specifically should be tested?

It all depends on your capabilities, the request, and the game’s format. The following options are available: 

Testing the first three to five hours of a game

If a game is quite large, full testing will be expensive and time-consuming. In this case, the client may request testing of only the first three to five hours of gameplay — that’s the most important stage for getting players hooked and keeping them engaged. 

Players also usually review a game after the first few hours of gameplay and tend to be less concerned about errors and omissions later in the game.

Testing for a set number of hours

This depends on the client’s budget. If it only allows for 15 hours of testing, that’s exactly how much time will be spent on LQA.

Testing a required volume

For example, if a client requires a game to be tested up to level 30, the number of hours and time frame will be determined based on that requirement.

Testing new updates

When an update is released it must also be fully tested.

We always recommend LQA by native speakers for at least the first three to five hours of gameplay. This will eliminate errors that could have slipped into the translation due to lack of context and which you might have missed because of insufficient knowledge of the target language.

What is the localization testing process?

1. We receive a task for testing.
2. We assemble a team.
3. We test the game based on the test plan and compose a bug report.
4. We consult with the translators on the recommended corrections.
5. The client makes the necessary changes to the game.
6. We conduct regression testing.

What is regression testing?

Regression testing is performed to make sure that the changes from initial testing were implemented and that all errors were in fact eliminated and will not appear in the release version. The ideal testing process is as follows:

1. First stage of testing.
2. Making corrections to the game.
3. Checking changes in regression.

Regression testing allows us to finalize the outcome of the first round of testing and be sure that all game texts are correct. This stage can be repeated if necessary, but in most cases one round of regression testing is sufficient.

We can conduct testing on emulators of various devices (such as an iPad emulator running on a PC), as well as on the devices themselves: PCs, tablets, and both Android and iOS smartphones.

What should the final product look like?

The bug report is the final product of testing. It is a report that guides developers in making subsequent changes to the game. It usually has a standardized form that describes each bug that was found. The report indicates the following basic information:

1. The type of revealed bug, for example: cosmetic or linguistic
2. The bug’s location in the game (or just the text ID from the lockit)
3. A description of the bug
4. Current status — how the sentence looks with the bug
5. Expected result — how the sentence should look
6. A screenshot with the bug or a link to one.

Conclusions

Localization testing is a very important process. It helps you refine a project’s text content and merge it appropriately with the interface. Skipping LQA only increases your chances of getting negative reviews from players. After your game is released, they will find all the bugs for you, lowering the game’s rating in stores and the total number of downloads.

So, if you decide to have your game tested:

• Prepare additional materials to help testers in the LQA process—the game build with cheats and in-game currency, a testing checklist, and lockit.
• Have the project tested by native speakers—it may be more expensive, but you get what you pay for.
• Check at least the first three to five hours of gameplay. They should captivate players and keep them engaged.
• Take advantage of regression testing to get the best outcome possible.

We wish you every success!