Game Development Reference
In-Depth Information
Now, for perhaps the last time, check that all the required pairs for the Multiple Routes
column are satisfied:
Quarter Length = “1 min�? is paired with “Yes�? (rows 1, 7) and “No�? (row 4).
Quarter Length = “5 min�? is paired with “Yes�? (row 2) and “No�? (rows 5, 8).
Quarter Length = “15 min�? is paired with “Yes�? (row 9) and “No�? (rows 3, 6).
Play Calling = “Package�? is paired with “Yes�? (rows 1, 8) and “No�? (row 6).
Play Calling = “Formation�? is paired with “Yes�? (rows 2, 9) and “No�? (row 4).
Play Calling = “Coach�? is paired with “Yes�? (row 7) and “No�? (rows 3, 5).
Game Speed = “Slow�? is paired with “Yes�? (rows 1, 9) and “No�? (row 5).
Game Speed = “Normal�? is paired with “Yes�? (rows 2, 7) and “No�? (row 6).
Game Speed = “Fast�? is paired with “Yes�? (row 8) and “No�? (rows 3, 4).
Challenges = “Yes�? is paired with “Yes�? (rows 1, 7, 8, 9) and “No�? (row 3).
Challenges = “No�? is paired with “Yes�? (row 2) and “No�? (rows 4, 5, 6).
Coach Mode = “Yes�? is paired with “Yes�? (row 1) and “No�? (rows 4, 5, 6).
Coach Mode = “No�? is paired with “Yes�? (rows 2, 7, 8, 9) and “No�? (row 3).
Well done! By creating a pairwise combinatorial table, you developed nine tests that
can test this set of parameters and values comprising 216 possible mathematical com-
binations (3*3*3*2*2*2). It was certainly worth the effort to create the table in order
to save 207 test cases! Also note that for this table you didn't have to resort to steps 6
and 7. That won't be true in every case, so don't rule it out for the future.
Now you are ready to test the game using the combinations in the table and check for
any irregularities or discrepancies with what you expect to happen. Create test tables
as early as possible, for example by using information provided in the design docu-
ment way before any working code is produced. Check any available documentation
to see if there is a clear definition of what should happen for each of your combina-
tions. That will equip you to raise questions about the game that may not have been
considered. This is an easy way to prevent bugs and improve gameplay.
A second approach is to ask people involved with code or requirements “What hap-
pens if…�? and read your combinations. You may be surprised how many times you
will get an answer like “I don't know�? or “I'll have to check and get back with you.�?
This is a much more economic alternative to finding surprises late in the project. It is
also much more likely that your issues will be fixed, or at least considered, by the time
the code is written.
