There are about a million ways to make the localization testing (LQA) process as inefficient as possible, making it cost time, money, and ensuring that is excruciating for all participants. Here, we’ll tell you how to avoid that.
Let’s start by briefly describing what LQA testing is and why it is so important. Localization testing involves comprehensive translation testing within the context of the game, and allows you to assess how the current translation will affect the game experience for players.
Five cool things LQA testing checks:
1. Integration Into the Game Context (making sure the translated stuff vibes well with the whole gaming experience).
2. Additional Quality Check (ensuring the translated texts flow, are easy to read, and all the gaming lingo is consistent).
3. Cultural Sensitivity Confirmation (checking that language is culturally appropriate and won’t make anyone cringe or feel awkward).
4. Optimizing User Experience (testing whether the localization enhances the overall gaming experience by ensuring clarity in tasks, understanding, and accurate conveyance of the original meaning).
5. No Symbols Gone Wild (ensuring all symbols and text are behaving correctly, so no weird stuff confuses players).
It’s great, isn’t it? That’s why we always recommend that developers don’t neglect checking localization before a game’s release. Now let’s get back to the main topic of this article: how to make that vital LQA painless!
Decide on the Team
Budget is of course at center stage, and it determines the composition and size of the LQA team.
You should hire someone for LQA who is attentive, skilled, responsible, and who has not translated the game in question, so they will be unbiased. We are not talking about a vendor, but about a specific performer: linguists are often involved in both translation and testing, so we make sure to check whether the testers were involved in working on the texts.
The team will consist of either native speakers or non-native speakers. The latter are typically cheaper, but if it is important to test culturalization, references, and jokes, or if there are doubts about the quality of the translation, it makes sense to budget for native speakers.
Carefully Consider the Style Guide and Preparation for the Project Launch
A great team doesn’t guarantee a perfect result. The client will need to call to discuss the style guide, provide references, and answer questions as the project progresses—and there will definitely be questions. Yes, this takes time, but it’s absolutely essential! The more information the client provides, the fewer invalid bugs they will have later.
It’s important to understand what exactly the LQA tester looks for and what things they can find. These are the most common bugs that we encounter:
- errors in translation, be they grammatical, linguistic, contextual, weird, funny, or may prove potentially offensive to part of the game community (which we would very much like to avoid)
- graphical flaws, such as text overflowing, loading the wrong lines or the wrong art
- functional bugs
- voice-over problems
- things that the client will point out, such as incorrect hyphenation in menus
- anything else because life is interesting
You can learn more about the different types of bugs in our article here.
By the way, functional testing and LQA are different things. That’s why during localization testing, testers won’t seek to break everything in the most sophisticated ways. However, any functional bugs encountered along the way will still be included in the report, unless otherwise requested at the beginning of testing. You can specify that you are interested only in the UI, menus, or some specific levels in the game. Then the job will be built accordingly.
Discuss the Form and Content of the LQA Report
In what form are your team most comfortable getting information? It might be an internal bug-tracking system that your in-house QA team is used to working with (e.g. Jira or Mantis), which will also work well for localization testing. It doesn’t take long to set up. If you don’t have such a system or need another tool, you can just use Google Spreadsheets. Ask your friendly PM, who will offer several tried and tested options.
By the way, the bug report can contain all kinds of information that is important to the developer. The default includes:
- Locale and build number.
- WTR/STR (ways/steps to reproduce). The steps to reproduce will be as detailed as possible, yet concise. They are necessary not only for the developer to find and fix the problem, but also to save time when checking fixes during the regression testing phase (the re-testing of the game after fixing bugs).
- Actual and expected results. The actual result will describe the issue, while the expected result will describe the fixed version. Almost always, the bug is also highlighted in a screenshot, so it becomes even easier to understand the issue.
- Lockit information, which includes the address/ID of the text in the file with translations.
- Initials of the tester.
We also often leave a comment field or a tag to indicate the status of an error because many linguistic problems can be corrected in the translation file. This way, the client understands which reports need developers’ attention, and which ones have already been resolved.
Make Sure the Build is Stable
The difference between LQA and editing is that the tester looks at the text directly in the game, so any problems with the build or difficulties in progressing will also cost money, time, and patience. If possible, it is better to provide a test plan or map of the game and cheats. The estimate for LQA with such inputs can differ strikingly (and in favor of the corporate account!).
Another important point to consider is there is a high probability that the team will be in different time zones. And if the customer makes edits to the game during testing and then updates the build, it can lead to a lot of *already* invalid bugs and delays in deadlines.
What’s the Bottom Line?
So, what do you need to do to ensure that LQA minimizes cost and maximizes value?
- Always spell out the details and provide all references for the most accurate and understandable style guides.
- Talk about the purpose of testing and point out what can be skipped and where you need more attention paid.
- Talk through all the points of the bug report.
- Make sure the build is stable.
- Work together with the LQA team to make the process comfortable for everyone.
- Don’t be afraid about asking the testing team questions.
- Don’t procrastinate when answering the testing team’s questions.
Localization testing is an important step. It may not always be noticeable, but it will affect your players’ experience. Our LQA team will always come ready to help, explain, and make the process comfortable and easy for developers. So test boldly, and may the players’ love be with you!
