Game – do you find Games Testing fun?
YES! The best part is being involved in the creative process. Whether it be interpreting something for a new culture, or making improvements that include actual gamers, it’s incredibly rewarding. When you can see your hard work in action on the final release of the game, it makes it all worthwhile.
What are the key components or methodologies of Games Testing?
There are 4 types of tests. First, there’s the Build Verification Test. The build verification test, or subsequent smoke testing, share the similar objective of eliminating potential bugs before localization testing starts. Typical build criteria include, is the build installable? Does it run? Is it free of major flaws? Can it be tested further?
The second is the Smoke Test. The typical sequence of steps in this brief and inexpensive test includes installing the application, starting it, creating a file using the application, saving and closing the file, and then restarting the application again. Next, open the file just created, make a few changes to it, save it and close again.
The third type of test is Graphical User Interface (GUI) Testing, which is performed once a build is accepted. The usual types of defects found include text expansion, resulting in truncated strings; GUI alterations, resulting in overlaps of GUI elements and controls or misalignment of their automatic hotkeys, resulting in duplicated hotkeys; hard-coded strings, resulting in untranslated strings; and missing or extra controls, resulting in missing or broken functionality.
And the fourth is Linguistic Testing, conducted by language-aware or native language testers on the actual localized product, running exactly as it would be used by local users in their own languages. Such testing is required, since much of localization takes place out of context, and much of the software testing is conducted by test engineers rather than language specialists.
There are different methods as well. Standard linguistic testing can be performed with language resources located onsite or in-house, in dedicated test centers or via local in-country staff.
Linguistic testing using screenshots of the localized product is another method, which can be conducted onsite or offsite. In this model, the language aspects of linguistic testing are separated from the engineering aspects. Non-linguistic test engineers prepare screenshots of all the requisite parts of the localized GUI and provide them to the language specialists, and remote access to a centralized test environment provided to linguistic testers.
What are the challenges you typically face in Games Testing?
One of the first challenges is the mythology the game is based upon, and the creative development required to adapt it to a foreign culture. For example, many ideas, characters, and lore that may exist in one culture do not exist in others – in fact, they may well be completely unknown! A game developed in one culture or country may even contain elements that another culture has never imagined.
The next biggest challenge is the fonts. Many games use typical Roman fonts, but when localized into other character sets, you have text expansion, contraction, tone marks, and many other additions that developers may have never considered when originally coding the game.
Are there any particular languages that are more troublesome than others?
Any language outside of Roman characters provides many challenges. Of course, Hebrew and Arabic present their own unique challenges, but generally, if you are outside the Roman language set, you’re going to run into issues that many developers never even considered when the game was first designed.
Is there any standard on how Bugs are defined and resolved?
Yes, we have a severity level as well as certain types. The type will always depend on the game. It is also important to prioritize the bugs and their severity.
Severity expresses the impact of a bug on the end user, usually scaled from 1-4.
1) Crash or hang bugs refer to loss of functionality, copyright issues, offensive text, etc.
2) Major bugs mainly impact functionality (or critical text is not visible).
3) Minor bugs are mainly cosmetic errors, and
4) Trivial bugs, which are the very small bugs like missing punctuation, for example.
After logging all bugs into the appropriate bug database, any outstanding issues or questions should be logged in the Master Question and Answer document. This document should be provided to the client each time updated source files or bug reports are sent.
The types of bugs that are typically found are hard coded strings in the code (that are not translated), concatenated strings in the code (that cause the ordering of a translated string to not make sense), key mnemonics mapped to native characters on the keyboard that don’t work (both accelerator keys and shortcut keys), GUI layout (often changes due to resizing of labels for text), some apps might need specific drivers for your target market (locale), if you have help files, they will need to be tested, and if you have web links, make sure they also point to the appropriate location (especially if those pages are localized)
What are the Top 3 Tips that will save money and time for a Games Localization project?
The #1 tip is to start early! The earlier you start to look at your code and prepare it for some of the bugs listed above, the more time and money you’ll save. Tip #2, start small. If you’re not completely comfortable going into multiple languages at once, start with one, learn the ropes, find mistakes, make a corrections plan, and build on it for future languages. Tip #3, invest in tools. At the end of the day, a human touch will always be required, but the technology available will make everything way more streamlined as well as consistent.