Localization quality assurance (LQA) is generally a service that third-party contractors are brought in to handle. There are different aspects to this, as well as different projects, and you never know what kind of supporting documentation you’re going to get. In some cases, QA testers only get the actual game or program they’re supposed to test; other times, they get a whole packet of information to accompany it. Both ways can work. But if that’s true, why bother sending anything at all besides the test build?
The difference is that QA work follows different tracks depending on what information the testers have access to. We put together the essentials kit of what you need for QA work. It includes:
• A build
• A test plan
• Reference materials
Let’s take a closer look at why all this is needed, as well as how QA works when we’re missing something from the list.
This one is easy. We can’t do without a separate test build or at least a link to a game that’s already released. There’s nothing to test otherwise. Of course, we can go through screenshots or videos you have prepared, though that’s a different story.
A test plan
This is where things get interesting. When there’s a test plan, the QA tester knows exactly what to go through and, more importantly, how to get to it in the game.
But if there isn’t one, the tester still knows what to check, as they have a genre-specific checklist we’ve put together. Still, that’s not a complete test. Even in the most linear games, there are bonuses or rewards that only show up when specific conditions are met. And it’s one thing if there’s a reward like “World’s Greatest Mayor” that has you build 100 residential blocks to earn it. That’s simple enough — build the houses, get the reward, check the text. But what do you do if there’s a reward like “World’s Worst Mayor,” only it doesn’t have a description? The tester has no way of knowing where to look for the text.
And how about cases where our job is only to go through a portion of the game rather than the whole thing? The only way to do that is with a test plan.
What a test plan does is define the QA testing and list all the areas in the game that are harder to get to (Figure 1). The only way to get the job done without a test plan is to jump in and plow on ahead, checking all the available windows.
Cheat systems are like oxygen for testers, letting them focus on the job at hand instead of just playing through the game. After all, if they don’t have a way to quickly pick up in-game currency or resources, they have to spend the time it takes to earn the one, and gather the other, on their own. And this can eat up tons of time the tester would otherwise spend getting the work done.
Also, cheat systems are critical for the second QA stage, or the regression testing, which is when the corrections made during the first stage are double-checked in action.
And it’s one thing if there are lots of bugs — we need to go through the whole thing anyway. But when there’s, say, one bug at the beginning and another at the end, there’s no point playing through the whole game yet again just to check on two little spots! In cases like that, cheats are critical tools that let testers jump right to where they need to go.
To take one example, in the good, old and sometimes fairly complicated Rome: Total War, there were lots of cheats that let you get money and units or win battles (Figure 2).
While regular players enjoy working their way through the game, testers have an issue waiting when, for example, a change in policy filters through to influence general welfare. That’s when the tester uses a cheat code like add_money 20000. And then there are unique events that only happen during certain time periods, which is when the date (year) cheat code comes in handy. The only other option is to wade through dozens of hours of gameplay.
Reference materials may not be the most critical item on this list, but that doesn’t mean they’re just fluff. Style guides and glossaries are critical. After all, when the phrase “Hey, bud, can you find my glasses?” is followed by “Please tap to continue the quest,” the tester can only take their best guess as to whether there was a mistake, or that’s just a different way of interacting with the player. The tester can ask about those points as they’re working, but taking the time to get the answers slows the whole process down.
And if there’s something going on between in-game characters or one of them has a particularly vivid personality that needs to be conveyed, it helps testers to know about that ahead of time. It’s sometimes hard to tell right away that some Don Pedro is actually a bashful guy in love with Maria, which is why he couldn’t just go up to her at the beginning of the game with a line like, “Hey, baby, why don’t we try our hand at a fiery flamenco?”
Focusing on QA
Basically speaking, the more material there is at the beginning of the QA process, the more of the tester’s time can go toward QA work as opposed to asking questions.
The cost and time frame can also depend directly on the materials we have in some cases. For example, when we’re doing a complete test of a game without a test plan, the first thing we have to do is analyze the game and put together our own internal test plan to make sure we have all the windows in the game covered.
QA companies asking for all those materials and information aren’t actually just trying to make their life easier, they’re trying to make sure the client gets the best product they can give them at the lowest possible price. For example, including cheat codes that cover all the available gameplay can more than cut in half the time it takes to run QA for the whole game.