In this presentation we introduce the most useful testing techniques in order to find bugs (ad hoc testing, combinatorial testing, test flow diagram, cleanroom testing and testing trees). These slides were prepared by Dr. Marc Miquel. All the materials used in them are referenced to their authors.

1. Lesson 2: Searching for Bugs
Third year course in Quality Assurance and Game Balance
Bachelor Degree in Video Game Design and Production
Third term, April 2019 Dr. Marc Miquel Ribé

2. Overview of the Lesson
In this lesson we will see:
QA and QC: Testing techniques
1. Ad hoc testing
2. Planning from techniques
3. Combinatorial testing
4. Test flow diagram
5. Cleanroom testing
6. Testing trees
Defect Trigger
Test Suites Exercise
Automated Testing
Testing World

3. QA and QC:
Testing Techniques

4. 1. Ad hoc testing
• When there is no testing, there is always a sort of testing. When there are no test
suites, there can still be some sort of testing. This is ad hoc testing, sometimes
called ‘exploratory testing’.
• Ad hoc testing, sometimes referred to as “general” testing, describes searching for
defects in a less structured way. “I wonder what happens if I do…?”
• Ad hoc testing presents you the opportunity to test the game as you would play.
Perhaps this is what you have been doing in your previous projects.
• Think of a big project instead: this may imply assigning members from different test
teams to do ‘ad hoc testing’ in other.
Ad hoc testing is the test of the “right-side
of the brain”. The creative side.

5. • Rotating testers. “Who turned the lights on?”. The “fresh eyes” concept is
applicable to structured testing as well. It’s wise to have testers rotate the specific
suites they’re responsible for periodically—even every build.
• Avoid “groupthink”. As a test manager you want testers to have different tastes
and habits, so their Ad Hoc testing has more quality.
• IMPORTANT: Even though ad hoc testing may be ‘more creative’, it needs to be
documented. If you are not ‘documenting’, you are not testing.
• How do you create ad hoc testing documentation? Instead of test cases and test
suites, you only define ‘goals’ and important conditions. You can use screen-
recording.

6. Reproducing bugs
• Ad hoc testing can turn into a “directed testing”, in order to reproduce specific
bugs.
• To “reproduce” is almost as using the Scientific Method
1. Observe some phenomenon.
2. Develop a theory—a hypothesis—as to what caused the phenomenon.
3. Use the hypothesis to make a prediction; for example, if I do this, it will happen
again.
4. Test that prediction by retracing the steps in your hypothesis.
5. Repeat steps 3 and 4 until you are reasonably certain your hypothesis is true.
Rate of reproduction is critical!
• What is best for a reproduction rate, a percentage or a number of times?

7. 2. Creating test suites
• The test case might focus only on a certain action, or a combination of menu options
that have been resulting in bugs up until this point.
• The goal, however, is to communicate from programmer to tester a specific thing that
needs to be tested.
Anything that the player can do is candidate to be a test case.
Test suites combine test cases that are “near”.
Developers should help the lead tester in creating the test suites.

8. Creating a test suite and incorporating it into the test plan is not easy.
• Why do we create test suites? For the same reason that we create documentation: to
manage work-load and work resources.
• How much documentation? How much testing is enough to trust the game? How
specific should be the test suites?
Well, these are the big questions. I (personally) answer them with three more questions:
What is the cost of lack of coordination?
What is the cost of test repetition?
How can we demand programmers to do better their job without ‘proof’?
How can we be sure we avoided the ’top priority’ highly severe bugs?
…
Some of the following ‘techniques’ help in preparing and executing reduced but useful
test suites which help in detecting bugs:
(1) Combinatorial testing, (2) Test flow diagram, (3) Cleanroom testing.

9. 3. Combinatorial testing
Testing Technique #1
Pairwise combinatorial testing is a way to find defects and gain confidence in the
game software while keeping the test sets small relative to the amount of
functionality they cover.
What might be the purpose of this technique? Clearly, to help in dividing the main
branches of the tree and not running them all.
It gives a ‘big picture’ to structure following tests cases.
For instance, the game may have: game events, game settings, gameplay options,
hardware configurations, character attributes, among others. (parameters)
Each of the parameters may have different values (enumerations, ranges, boundaries,
etc.). Consider that “going to a place” or ”playing at a certain speed” a combination.
Combinations may rise to hundreds or thousands.

10. This test combines character attributes for a Jedi character in a Star Wars game to
test their effects on combat animations and damage calculations.
We may want to test different combinations with our fighters in Star Wars,
considering the following parameters: gender and light saber. Later, we want to add
the side of the force the are.
Complete three-way combinatorial table for Jedi combat.
2^3 = 8 rows

11. Pairwise combinatorial tables let you add complexity and coverage without increasing
the number of tests you will need to run. We do not need all the combinations, we
only need all pairs of components being tested.
• Male Gender paired with each Light Saber choice (1H, 2H) (row 1, row 2)
• Female Gender paired with each Light Saber choice (1H, 2H) (row 3, row 4)
• Male Gender paired with each Force choice (Light, Dark) (row 1, row 2)
• Female Gender paired with each Force choice (Light, Dark) (row 3, row 4)
• One-Handed (1H) Light Saber paired with each Force choice (Light, Dark) (row 1, row 3)
• Two-Handed (2H) Light Saber paired with each Force choice (Light, Dark) (row 2, row 4)
This is a completed
Pairwise combinatorial
Table!

12. The process to construct
1. Choose the parameter with the highest dimension (more number of values).
2. Create the first column by listing each test value for the first parameter N times, where N is
the dimension of the next-highest dimension parameter.
3. Start populating the next column by listing the test values for the next parameter.
4. For each remaining row in the table, enter the parameter value in the new column that
provides the greatest number of new pairs with respect to all of the preceding parameters
entered in the table. If no such value can be found, alter one of the values previously entered
for this column and resume this step.
5. If there are unsatisfied pairs in the table, create new rows and fill in the values necessary to
create one of the required pairs. If all pairs are satisfied, then go back to step 3.
6. Add more unsatisfied pairs using empty spots in the table to create the most new pairs. Go
back to step 5.
7. Fill in empty cells with any one of the values for the corresponding column (parameter).
EXERCISE: Let’s use the preceding process to complete a pairwise combinatorial table for some
of the NFL 2K5 Game Options.
Quarter length (1, 5, 15 min), Play Calling (Package, Formation, Coach), Game Speed (Slow,
Normal, Fast).

13. We need to verify that each pair exists and
write between parenthesis the row number.

14. Let’s use the preceding process to complete a pairwise combinatorial table for some
of the NFL 2K5 Game Options.
We need to verify that each pair exists and write
between parenthesis the row number.
If we want to add more complexity, we could add
more parameters: Challenges (Yes/No), Coach
Mode (Yes/No).
Let’s suppose we already introduced challenges…

15. We need to verify that each pair exists and write between parenthesis the row number.
When we ‘verify pairs’ we only need to write up the new pairs, not the old ones…
In any case, in a company you might use an algorithm to generate the table. Or combinatorial
templates.
It’s time again to check that all the required pairs for the new column
(Challenges ) are satisfied:
Quarter Length = “1 min” is paired with “Yes” (rows 1, 4) and “No” (row 7).
Quarter Length = “5 min” is paired with “Yes” (row 5) and “No” (rows 2, 8).
Quarter Length = “15 min” is paired with “Yes” (row 6) and “No” (rows 3, 9).
Play Calling = “Package” is paired with “Yes” (rows 1, 6) and “No” (row 8).
Play Calling = “Formation” is paired with “Yes” (row 4) and “No” (rows 2, 9).
Play Calling = “Coach” is paired with “Yes” (row 5) and “No” (rows 3, 7).
Game Speed = “Slow” is paired with “Yes” (rows 1, 5) and “No” (row 9).
Game Speed = “Normal” is paired with “Yes” (row 6) and “No” (rows 2, 7).
Game Speed = “Fast” is paired with “Yes” (row 4) and “No” (rows 3, 8).
Challenges = “Yes” is paired with “Yes” (row 1) and “No” (rows 3, 7, 8, 9).
Challenges = “No” is paired with “Yes” (rows 4, 5, 6) and “No” (row 2).

16. 4. Test flow diagram
Testing Technique #2
Test flow diagrams (TFDs) are graphical models representing game behaviors from the
player’s perspective. Testing takes place by traveling through the diagram to exercise the
game in both familiar and unexpected ways.
• It is not a flowchart, it has nothing to do with algorithms.
• Why draw diagrams? Because it is easier for some people to think visually.
• Parts of the diagram: terminators, flows (events and actions) and states.
We want testers to think of the game from the player perspective and plan test cases.

17. Terminators – are represented as boxes that indicate where testing starts and ends
Events – are operations initiated by the users.
Actions – exhibits temporary or transitional behavior in response to an event.
States – represents persistent game behavior and are a re-entrant. They are ”bubbles”.
Flow connects one game state with another.
The TFD does not have to represent all possible events for the portion of the game
being tested. Events should be considered according to the unique or important
behaviors related.
Events, actions and states
are known as primitives.

18. Creating a TFD is not as mechanical as Combinatorial Tables. They could be useful to test
gameplay or map transitions between quests, matches or challenges (e.g. what if I get all the
solo mission complete and then I do individual quests?).
You can use paper and pencil, SmartDraw or Microsoft Visio.
The idea is to create a TFD and gain detail.
Let’s put an example: the ability to pick up a weapon and its ammo while the game properly
keeps track of your ammo count and performs the correct audible and visual effects

20. Main Advantage of the TFD? It helps you to not forget any path!
Main Disadvantage of the TFD? It may get too complex sometimes!
• Remember: Each event is like a test case.
• You can reuse some of its states and events among different test suites.
Data Dictionary. It is usual to create internal ”wikis” (as documentation) with
clarification for the effects associated to each event in the TFD.

21. Baseline path as direct as possible, with as
many states as possible, without repeating
states or looping back. This is useful as it is
prioritized. The Baseline path is 1,2,4,13
Derived from flow 1:
1,9,8,2,4,13
1,11,10,2,4,13
Derived from flow 2:
1,2,3,4,13
1,2,7,2,4,13
Derived from flow 4:
1,2,4,5,4,13
1,2,4,6,4,13
ALERT. Flow 12 is not covered.
We can use 11 with the baseline:
1,11,12,8,2,4,13
Derived paths are complementary variations to the baseline.
They propose alternatives at each event/action taken.

22. • Finally, you can ’translate’ the TFD into a list of test cases with “what to do” and
”what to expect”. TFD are useful to prepare the testing.
Depending on what to test, it is easier to use one or another technique in order to
create a list of test cases.

23. 5. Cleanroom Testing
Testing Technique #3
The original purpose of Cleanroom testing was to exercise software in order to make
mean time to failure (MTTF) measurements over the course of the project.
If we fix the most common bugs, then, the time between failures increases.
Cleanroom testing aims to produce the tests that play the game the way players will
play it at their homes.
The goal is to prevent the most common problems that players would encounter.
Therefore, we can obtain usage information in order to assign different probabilities:
• Mode-based usage
This may involve: single player, campaign, multiplayer, and online.
• Player-type usage
Taking into account Bartle’s Taxonomy, for instance. Or the statistics of the industry.
• Real-life data
Taking into account data from the current players.

24. Cleanroom combinatorial tables will not be “pairwise” combinatorial tables. They are created by
the “test designer” by estimation. Let’s take this example with four invented player profiles.
These would be the parameters for the game HALO Advanced Controls.
Look Sensitivity: 1, 3 (default), 10
Invert Thumbstick: Yes, No (default)
Controller Vibration: Yes (default), No
Invert Flight Control: Yes, No (default)
Auto Center: Yes, No (default)
These tables would be our estimations for
each player profile:

25. We want to create 6 test cases. Then, we call six randomly generated numbers: 30, 89, 77, 25,
50 and 97. We use the Casual Player.
Look Sensitivity for the Casual player has these intervals 1-10 (1), 11-95 (3), and 96-100 (10).
The first random number is 30, so it falls between 11-95 and the value for the first row of the
table is 3. We then repeat the procedure for each of the random numbers. Look Sensitivity is 3
all the time but the last one, which is 10 (because 97 is in the third range).
We can then repeat the procedure with 6 more random numbers and the second parameter
table (Invert Thumbstick) and check the intervals for the Casual player. Then we would repeat
for the third parameter…

26. How do we apply Cleanroom to TFD?
By assigning probabilities to paths
following a personal criteria.
Very similarly, we use random
numbers, then we calculate the path
by using the probability.
With random numbers: 30, 27, 35, 36,
82, 59, 92, 88, 80, 74, 42, and 13.
We would obtain the path: 1, 3, 4, 7,
9, 11, 7, 9, 11, 7, 9, 11, 6.

27. 6. Test trees
Testing the combinations of peripherals, game modes, configuration options, game
paths, would take literally an army of testers.
Again, what do you want to cover? What should we cover? How do we start?
We are blindfolded…

28. One approach is to re-create the different “test trees” in the game (Schultz, Game
Testing, 2011). These are useful classifications in order to design proper test suites.
“Test trees” are tools to identify and create the necessary test cases and test suites.

29. There are various types of threes:
1. Test case tree. They are useful to document the hierarchical relationship
between test cases and game features, elements, and functions.
2. Tree feature tests. They reflect the tree structure of features or functions
contained in the game.

30. 1. Test case tree
Test case trees document the hierarchical relationship between test cases and game
options, elements, and functions.
Think of it as a prior step to design
a list of test cases (test suite).
If we update the code for the game
mode “Skirmish” from the RTS game
Dawn of War, we need to think of test
cases to cover the possible relationships.
It does tell us the depth, not that we
should do everything. It is a good starting
Point.
QUESTION: From the test case tree example, which test branch(es) should you re-run for a
new release of the game that fixes a bug with the sound effect used for the Orks “Big Shoota”
weapon? Ideally and pragmatically?
What functionality is available where

31. 2. Tree feature tests
Tree feature tests reflect the tree structures of features or functions designed into
the gameplay.
Let us think of Final Fantasy Tactics Advance. Characters need to develop certain skills at one or
more jobs before other choices become available.
We create the test cases
What happens when

32. Terran technology tree from Starcraft.
QA needs the this ’tree’ to create tests which verify the availability of each of the
elements at the precise moment.

33. Many elements may be structured as “tree feature test” and it can be really useful
to define test cases. Think of the following features:
• Technology trees
• Advancing jobs, careers, or skills
• Progressing through tournaments
• Adding or upgrading spells, abilities, or superpowers
• Increasing complexity and types of skills needed to craft or cook items
• Earning new ranks, titles, trophies, or medals
• Unlocking codes, upgrades, or power-ups
• Unlocking new maps, environments, or race courses
• Unlocking better cars, outfits, or opponents
Some games may be more linear than others and facilitate this (!)

34. Defect Trigger

35. Defect triggers
We want to design test cases that are likely to find bugs. This can help us.
Orthogonal Defect Classification (ODC) system developed by IBM allows to classify
defects into types in order to reveal how they were introduced, be found or avoided.
You may remember them from Lesson 1: Function, Assignment, Checking, Timing,
Build, Algorithm, Documentation and Interface.
Orthogonal Defect Classification (ODC) also includes a set of Defect Triggers to
categorize the way defects are caused to appear.
Test cases can also be thought according to the triggers.
Defect trigger can also be included in the bug description!
Test suites that do not account for each of the triggers will be incapable of revealing
all of the defects in the game.

36. Game software operating regions
The game operation can be divided into different regions. These are conceptual mappings
to the game. They can be applied to the game as a whole or to some parts such as levels,
missions, etcetera.
The pre-game has the hardware functioning but the game has not started.
The game start has some cinematic, p.e. loading progress, and some basic functions are
happening.
The in-game is the actual gameplay where the player interacts.
The post-game is all the possible ways and process of quitting. It can include cinematics,
saving, etcetera.

37. Game software operating regions
Six Defect Triggers span the four game operating regions. These triggers describe ways to
cause distinct categories of game defects to show up during testing. We can use these
triggers to create test cases.
• The configuration trigger (usually in the pre-game region).
• The startup trigger (e.g. operations while game function is starting, graphics loaded,
variables initialized, etc.).
• The exception trigger (e.g. special parts of the game; alerts for network problems).
• The stress trigger (e.g. specific conditions: memory, screen resolution, disk space, etc.).
• The normal trigger (e.g. game operations in the in-game operating region).
• The restart trigger (e.g. failure as a result of quitting wrongly, ejecting the disk, etc.).

38. Examples:
“The sniper rifle now reloads automatically in all game modes. It no longer waits for the
player to let go of the fire button”. Restart
“When playing a Disintegration match in MultiMatch, the reload delay for the sniper rifle
is now shorter”. Startup
“Saved game issues with long computer names fixed”. Stress
“Mouse 4 and 5 sensitivity levels are not available in the Configure menu”. Configuration

39. Examples:
“The Explosive damage has been increased”. Normal
“Death will no longer break the chat in MultimMatch, when it should be
disconnected until the respawn”. Restart
“Teams are no longer automixed on map restart in MultiMatch”. Restart
“The server will not inform the player if he votes to switch to a map that does not
exist on the server”. Exception

40. Example: Ammo TFD template with Stress flows highlighted.

41. EXERCISE:
“Texas HoldEm Poker Deluxe” Android Play: Texas Hold ‘Em poker has become very
popular recently and many videogames on various platforms are popping up to take
advantage of the present level of interest in this card game.
Now, make a list or outline of how you would include each trigger (Configuration,
Startup, Exception, Stress, Normal, Restart) in your testing this game.
• Don’t stop at one example—list at least three values, situations, or cases for each
of the non-Normal triggers.
• Remember to include tests of the betting rules—not just the mechanics and
winning conditions for the hand.

42. Besides the Normal trigger testing, which you are accustomed to, here are some ways to
utilize other defect triggers for this hypothetical poker game:
• Start-up: Do stuff during the intro and splash screens, try to bet all of your chips on
the very first hand, try to play without going through the in-game tutorial.
• Configuration: Set the number of players at the table to the minimum or maximum,
set the betting limits to the minimum or maximum, play at each of the difficulty
settings available, play under different tournament configurations.
• Restart: Quit the game in the middle of a hand and see if you have your original chip
total when you re-enter the game, create a split pot situation where one player has
wagered all of his chips but other players continue to raise their bets, save your game
and then reload it after losing all of your money.
• Stress: Play a hand where all players bet all of their money, play for long periods of
time to win ridiculous amounts of cash, take a really long time to place your bet or
place it as quickly as possible, enter a long player name or an empty one (0
characters).
• Exception: Try to bet more money than you have, try to raise a bet by more than the
house limit, try using non-alphanumeric characters in your screen name.

43. Three more conclusions regarding Test Case and Test Suite definition:
1. Test cases need to be specific about a single thing (you need to understand well the
game elements to design test cases).
Think of external documentation if you want to extend the description of specific
effects in the ‘expected results’ of the test.
2. Consequently, test cases need to be detailed with “conditions” if they are not in an
ordered test suite.
3. Test case order matters (make the tester’s life easier and he will be more efficient).

44. Test Plan with Test Suites

45. Test Suites in Test Plans (Example)
In three minutes, “what tests suites would you include in the test plan for X game?”
This could be a “key question” in a job interview for a video game company.
What would you answer?

46. The first answer is simple…“It depends on the time and budget constraints”.

47. Test Flow Diagram, Pairwise Combinatorial Tables, Cleanroom Testing, Test Trees, Defect
Triggers…They all could help you to design the right test suites for all these games.
Exercise: Propose different testing techniques for each game.

48. Are you thinking about the Test Plan for your game?
• How many test suites?
• How many types of testing?
• Are all defect triggers covered?

49. Automated Testing

50. Automated Testing
Automated testing provides methods in order to test by using software and compare
later the actual outcomes with the expected outcomes.
Some argue that all should be automated; others are convinced that it is only viable
in few specific instances.
Some reasons why Automated testing can be useful
• Consistency of results in different devices (case of the mobile).
• Faster testing.
• Performance issues (fps in specific moments, CPU usage using AI, etc.).
• Large number of concurrent players for stress and load testing.
• Improving game reliability.
Some reasons why Automated testing is not always useful
• Some specific movements and transitions are not possible.
• Some expected outcome may be not possible automatically evaluate.

51. Difficulties that prevent from embracing Automated testing
• Production-costs can be very high if you want to try all the test cases
automatically. You have the project more time in dev.
• Reusability of automated testing is not clear, since every game has new code.
• Large-scale automated testing implies a) very well-trained teams, b) big projects
with big budgets.

52. What games *must* we automatize? Massive Multiplayer Games
• The Sims Online, World of Warcraft, etc. are games which can be automatized as
they have a high number of repetitive actions, must simulate a very large number
of players, are synchronized among a large number of servers and clients, etc.
• Many other types of games can benefit from automated testing, too. Level-based
games such as first-person shooters could have sequences of play tested by well-
written scripts that imitate a player repeatedly shooting in a certain pattern.
Certain patterns: not all patterns.

53. Integrating Development with Testing Environment
SimScript: The TSO team used a subset of the main game client to create a test client
in which the GUI is mimicked via a script-driven control system.
SimScript is an extremely
simple scripting system.
As it is intended to mimic
or record a series of user
actions, it supports no
conditional statements,
loop constructs, or
arithmetic operations.
Stored procedures and
const-style parameters
are used to support
reusable scripts for
common functionality
across multiple tests.

54. Integrating Development with Testing Environment (Testdroid from Bitbar)
• Testdroid tells us that we should not test with emulators and instead use their
infrastructure to test with real-devices with an automated environment.

55. • TestDroid uses testing frameworks such as Robotium and Appium.
• Appium Framework to code scripts / test cases for a game (based on JUnit). Then,
using Testdroid Cloud service to select devices.

56. • Appium Framework to code scripts / test cases for a game (based on JUnit). Then,
using Testdroid Cloud service to select devices.

57. Utilities of Cloud Testing in mobile phones
While running a game on cloud-based real devices, check the following things:
• The game’s graphics and UI
• Are the controls all usable (buttons, menus, boxes) in all devices?
• Is the navigation flowing smooth?
• How much delay is there between game stages?
• Screen resolution – how does this affect the operating system version?
• Screen orientation – does the device react the way it is supposed to?
• Are animations flowing well?
• Are fonts implemented properly?
• Image recognition is another “trend” in automated testing.

58. Graphic testing is part of the automated testing set of tools in order to detect flaws in
performance. It compares real-time generated images in a specific device with
previously stored images.
From left to right, the reference image, test result image and finally the diff image.

59. Real example from Automated testing with the game Clash of Clans:
• Test Script contains the following 'steps':
1. Identify the used platform (Android / iOS)
2. Search for 'Goldmine' graphical element (using find image to search for screen)
3. Script runs test to go to shop
4. Script runs test to buy a cannon
5. Script runs test to place the cannon (all these three are defined in .png files)
6. Script runs test to start a battle!
7. Game is brought down and test ends.
Simple actions just to test compatibility with devices.
Sometimes we ‘trust a bit’…
We cannot detect very specific transition states in all mobile phones as the cost for
repeating tests would be high and it would not make sense to find a bug in one
device and not in another.

60. Performance testing in Mobile phones
• Good performance is a requirement to
good user experience. User wants to see
constant progress with the game, do the
smooth gameplaying, graphics
performance needs to be up to snuff and
work across all different mobile devices
(phones, tablets etc.) the very same.
• Typical metrics from performance tests are
CPU load, memory consumption and
frames per second (FPS). Based on them,
coders can work better.
• Load testing. More oriented to the infrastructure and its optimization (testing the
number of connections, CPU of the servers, etc.).
• Stress testing. More oriented towards understanding how the game scenarios relate to
the device characteristics. Looking for the peak of resources or number of users is called
“spike testing”, while “soak testing” is checking performance along time.

61. Capture/Playback Automation
Capture/playback test automation is like using a digital video recorder while you test.
Your inputs are recorded as you play the game and at various points you designate,
screen images are captured for comparison whenever you “replay” the test in the future.
Testdroid supports scripting of Unity3D Games (Testdroid Recorder).
It generates a code out of the player’s action.
QUESTION: At what times it can be useful?

62. Automated Testing: Summary of Pros / Cons (Again)
Pros:
- It can save many man hours and can be more “efficient” in some cases.
- It can be useful to do compatibility testing with multiple devices.
- It can be invaluable to do stress testing, load testing, etc.
Cons:
- It will cost more to ask a developer to write more lines of code into the game (or an
external tool) then it does to pay a tester (in general) and there is always the chance
there is a bug in the bug testing program.
- Reusability is another problem; you may not be able to transfer a testing program
from one title (or platform) to another.
- And of course, there is always the “human factor” of testing that can never truly be
replaced. There are things you cannot imagine trying with automated testing.

63. Testing world

64. Tester Profile and environment
• What are some unknown facts about game testing?
- “Playing games for a living”. No: methodical work in pressure conditions.
- “You know the games before everyone”. No: broken games and small parts of it.
- It is impossible to fix everything. Testers do not fix, testers are sometimes asking for
something to be fixed. It is a whole new perspective.
- Good QA and QM is closer to engineering (planning, efficiency, management, etc.).
• What are the daily responsibilities of a QA tester?
- The test suite/document you have been assigned to. Work is delimited. These is the
real responsibility for which they can fire you.
- To find new bugs, even though you accomplished with the test suite, ad hoc testing
is sometimes an unnoticed requirement in the inner team competition.
- Reporting in a proper way so the programmer can save time. Testers may not have a
high reputation from the perspective of the development team.
- You need high skills to perform certain movements at the level it might be required
to test it (for the entire day). Testers need to be gamers.

65. • What are the working conditions associated with a testing team?
- Some profiles need to be temporary as they only fill the requirement for the
project. Others can get a regular job, as the company continuously release games.
- Lower paid than programming and software testing. Companies know the profile
for the end-tester is low and very few get paid properly.
- Competition is part of the team ethics (not for promotion though), as bugs are
their trophies. Good tester is a meticulous, methodical, and always ready worker.
- Most testers have a low studies profile and therefore stay in that specific niche,
even switching from one company to another (in best cases they learnt to code).
• What are some demographics associated with testers?
- The largest share of the group is in their twenties (62% 22-25). They are usually
men (70%) with a prior enthusiast about video games. Testing does not kill love
towards games, neither it increases it.

66. • What are some tester types? (in an humorous tone; Levy, Game Development
Essentials: Game QA & Testing; 2009)
Blank: This character has no memories, skills, knowledge, or equipment. This is the
tester who likes to play games and, following a friend’s “advice,” applied for a game
testing position. Blanks can either learn from the best and become pros, or resign
themselves to boredom and sleep on the job.
Technician: Technicians are ... technical. They often have attended at least one
technical school, and they might even be programmers already. Lacking observational
skills, the Technician doesn’t have the best “eye”—and can’t hear that well either.
Technicians can, however, break through the toughest bugs.

67. Artist: Artists love film and music and are usually able to draw and paint. Artists have
amazing eyes. They can see every single visual bug—even the smallest ones. They
spot z-fighting (when textures seem to “fight” with each other). Lack analytical skills.
Hybrid: A Hybrid has the soul of an Artist and the skills of a Technician—often
someone with a programming background, but who enjoys drawing on the side.
Hybrids can be maddening. Sometimes their skill levels are simply not high enough
for them to actually crack a bug’s steps. Sometimes they turn into leaders.

68. Stone: Most Stones are useless but, again, some hidden talent might shine under all
that immobility. Sometimes, Stones are excellent at full-on speedruns (playing
through the game really fast) because their concentration skills are unmatched. On
the other hand, they might not be the best communicators—and neither care about
nor follow hierarchy.
Berzerker: Berzerkers seem to thrive on chaos and may actually fear a peaceful work
environment. Berzerkers might be good at testing, maybe even phenomenal, but they
make everything personal and more difficult than it has to be.

69. Mini-Boss: Mini-Bosses tend to be frustrated Artist or Technician types—and most of
the time they are older than other testers. Mini Bosses think they have power—but
they’re testers just like everyone else. Even if Mini-Bosses indeed have talent, their
poor social skills annihilate any chances of promotion.
Elf: They don’t go to work as game testers because they see it as a career; no, Elves
test games because it’s cool. They also like to speak up to Executive Producers in the
middle of do-or-die team meetings. They end up leaving.

70. 7. How to enter and escape
What can you do to enter?
• Companies websites and openings (King, Blizzard, Zitro, etcetera.)
• Job board sites (Infojobs).
• Participate in Open beta testing and get noticed.
• Sites to learn more about the profile (becomeagametester.com)

71. QA high positions end up in
management.
This is the CV from someone who made the
QA from Square Enix much more efficient.

72. QA Engineering is oriented towards white-box
and designing tests for testers.

73. The end tester often is not
required to have any
experience.
However, in the employer
wishlist, there is knowledge
on automated testing and
development methodologies,
which are unlikely for a
starting position.

74. Do you need to leave testing?
• You are not being promoted; you are never given any complex tasks; your only
motivation is to feel “safe”.
• This is a reasonable career path if the tester is a good professional. In three years,
he might become a Lead tester for some games.
QA is a good entrance door for video game companies, but it is good to keep moving.