In the quality-assurance (QA) stage of development, you take your working game and test it heavily. (Depending on who you work with and how irreverent you are, you may hear, or make up, more descriptive terms for putting your game through its paces, such as "beating the heck out of it" or "making it cry.") You are looking for bugs and usability issues. Typically during this stage you put your game in front of several people who have not been involved with its development, give them some general direction and requests, and let them have at it. It's amazing the number of bugs that someone unfamiliar with your game can find in a very short time. After your testers are finished playing your game, ask them questions like:
Were the instructions clear?
Did the game make sense?
Was the game fun?
Did it hold your attention?
What changes or enhancements would you suggest?
Did you notice any bugs? If so, what were they?
Did anything happen that kept you from finishing the game? If so, what was it?
How were the sounds and music (if any)?
If you don't receive comments on your sound, take that as a good sign! When integrated properly into the game, sound is something most people will not consciously notice. However, if it's done poorly, people will be aware of it and comment on it.
You can treat this process as formally or informally as you like; for example, you can give your testers an official questionnaire. This has the dual benefit of providing them with an easy way to quantify their information, and you with answers to consistent and specific questions. I've created a checklist (QA_checklist.pdf) that you'll find on the CD, in the Chapter02 folder.
Armed with answers to these questions, you can make well-informed decisions about how your game can be improved. You may find that you run through this QA process multiple times until you get the response you want from your testing group.
The primary reason for planning ahead and using a process is to make your work go more smoothly. Without proper planning, you may find yourself having to abandon some of your work (due to unforeseen problems) after investing time in it. Following the process discussed in this chapter, you will be able to take your game idea, break it into logical pieces, identify the possible problems before they occur and solve them, and then assemble the game.