TESTRONIC TALK: We’ve got how long for LQA?

After 15 years supplying QA for hundreds of games industry clients, I can’t entirely discount the possibility that the above might, occasionally, bear some vague approximation to the truth…

Perhaps one critical path playthrough is all that’s needed to trigger every in-game string, and there are no additional modes or optional content. Checking the localised system messages and terminology required to pass each console’s submission requirements takes several hours, but a single mobile platform wouldn’t need that. If we are provided in advance with solutions to puzzles and good debug options, that will also save time.

We’d also have to assume a low frequency of issues found. LQA testers correct linguistic mistakes, plus contextual errors where translators didn’t understand where or how strings will be used. They also report language-specific implementation errors, from unsuitable font choices, to out of synch cut-scene subtitles that require line by line timing adjustments. The build we test would also have to be free from major functionality errors that might set back their progress.

I remember receiving a request for a thorough LQA pass on an adventure game that had somewhere in the region of 70,000 to 80,000 words. My contact initially asked us to trigger 100 per cent of the strings on-screen, but had based his internal expectations on the fact that one of their FQA testers reached the end of the game in 10 hours, so hopefully LQA might just need a little longer than that.

As anyone who likes adventure games knows, the majority of text is not seen by making progress, but by trying the ‘wrong’ conversation options, in humorous results when attempting to use inappropriate items on the environment or each other, and in optional descriptions that appear when examining or interacting with every red herring. In other words, everything but the steps in the walkthrough.

The client appreciated how they had underestimated the time needed when we pointed out that it would take a professional proof-reader 10 days or more to review that volume of text if they were working purely with the text files and not having to play anything. A tester would therefore need even longer, as they need to find and trigger each string before they check it.

Here at Testronic, we will always collaborate with our clients on how long we think we should test their product for. Forging good partnerships requires us to remain flexible to each project’s unique requirements and a willingness to adjust strategy and find compromises that respect any constraints such as submission deadlines or budget limitations, while setting coverage expectations realistically.

For the example of the adventure game, the client didn’t have the budget to pay for what they initially asked for, so after suggesting various strategies that would fit their financial constraints, we agreed that a sensible approach would be to check only certain strings on-screen (front end, in-game menus and UI, critical path playthrough, and compliance related strings). After that we would proof-read other commonly seen strings in the text files, using our experience thus far to flag consistency or contextual problems, shortening strings we now knew would overrun their text boxes, and finally provide brief spot checks only of the rest.

Working with as many clients as we do, there’s a vast range of experience amongst our contacts, from QA veterans that come to us with up front schedules, instructions, and realistic coverage expectations, to new indie developers that have no prior experience with localisation. Perhaps their first mobile app has had some success in English, they are considering localising for additional territories, and are asking us what the difference is between Traditional and Simplified Chinese (Short answer: Simplified is for mainland China). For them we might provide a range of different scenarios representing different combinations of language and coverage expectations, while they work out their budgets.

For some, LQA is one of the last aspects of a project to think about, and it certainly gets less media coverage than functionality QA (compared to a visually amusing FQA bug, you have to be a bit of a language nerd to appreciate a good text error!). Nevertheless, it’s a fascinating field to be working in with plenty of its own challenges, and I’m proud to be working with so many great clients at one of the best LQA providers in the industry.