You make your game. It's playable. Oh em gee. So now we test.
...This is where most people go the wrong direction.
Testing a game isn't about fixing the bugs. Of course, you should always do your best to keep the glitches out of the game. That's obvious, but fixing bugs is something to do more often when you're actually developing the game and not entirely into the "testing" phase.
When you're testing your game, you have one goal:
Make this game not suck.
It's pretty simple and easy to do. Gather a handful(best to have a variety of people with different preferences, ages, etc. Try to reach the widest chunk of your target audience that you can- stupid, smart, casual, hard-core, etc. Don't even worry about whether you have a huge audience or not- Most of the time when you take the risk to go for a super-specific niche, you'll reach everyone. [minecraft, swords & sworcery, legend of grimrock)
Sometimes your tester can be any random dude who decides to give your game a spin. In fact, when you're testing your game to fix your gameplay problems just about every single person who plays it is another test subject.
Think of yourself as GLaDOS. You won't even need cake(since it's a lie). Watch every player carefully, and see how they play your game. An easy way to collect information is to see the key points where a user logs off, complains about something, dies, etc. Note things like what makes them raeg, what makes them laugh, and the habits the player builds. Be very open to criticism and feedback- A tester who isn't afraid to vocalize his opinion will be a very useful asset to you. Chances are high that if one person has a problem with a certain level or game-play aspect, then everyone does.
And when they tell you what's wrong, they're literally doing the work for you by figuring out why your game isn't that 1337 masterpiece it was in your head. A couple tweaks and changes can dramatically change a game for the better.
It's important to be very dynamic with your development, 100% of the time. Don't EVER restrict yourself to some stupid design document you wrote up before development. If the game isn't fun, then the game isn't fun. Learn that fixing a key aspect of your game can be as simple as writing out 10-20 quick lines of code.
i'd write more on this but i think you get the point. this is the testing process I used for Epic, and the reason I'm writing this is because dynamic game-play testing and development is a process used by the mainstream(valve takes pride in their flexibility)
As with all things, game design and development will come easier to you the more experience you have making games. If you make 10 mini-games and the last three or four are actually pretty fun, that is because you learned a lot from making the first 6. Compared to the guy who hasn't made a single game but has dedicated his life to making one huge project over the same amount of time(and possibly equal amount of effort) you have a lot more experience. But that's a totally different blog. Today we're talking about testing... lol