Planning to Test

The only way to make sure software works correctly is to test it. But what do you test? What are you testing against? What criteria determines whether a test passes or fails? This is all part of the Test Plan. Each team's Test Lead is about to get busy.

You need to write a test plan. It is going to be the guideline for your team when they come to do test your game. There are lots of different ways to write these - we are going to keep ours simple. We pretty much want to generate a testing checklist for the team to run through when they test the game.

Starting Points:
In general, what assertions does the game design document (GDD) make that you need to verify in a test?

• e.g. "The player uses the arrow keys to move". Does this actually work? This probably ends up as a bullet point on the testing checklist: 'Verify that arrow keys move the player'
• e.g. "The counter counts down from 5:00 mins. When it reaches 0, the game ends". Does it actually count down from 5 minutes? Does the game end when it reaches 0?

The Test Lead makes a list of the 'assertions' in the GDD, and as specified by the team members also, when not covered by the GDD.

The Test Lead then defines simple processes to test each of these points. Sometimes this isn't so 'simple', and there is only so much that you can reproducibly test, but do what you can :).

• e.g. Run the game, verify that the title screen shows for 3 seconds.
• e.g. Verify that the player walking animation is shown when pressing right or left, but the jumping animation plays when pressing up.
• e.g. When the player collects a tomato, their score increases by 3.

The next part will be to define what happens once someone finds something wrong. A team member is running through the checklist and finds a defect. What do they do? How do they record it? How does it get fixed? How do we know it is fixed?

These questions and more, answered next time..