But resist the temptation to quit. Understand that testing is an inextricable part of good design; what you're making is for the player after all.
You Are Not Your Work
I feel a little silly parroting this again, but it's worth it if gets through to just a few more people. Remember the lesson of every teary-eyed critique in art classes the world over--you are not your work.
It is of you, but it is not you. While you may be deeply invested in it, once you have made something it is out there in the world and separate from you. No matter how coarsely phrased a criticism may be, remember it is a reflection of the work and not you personally.
There are creative professionals that get by without learning this but boy does it cause them no end of grief. The pride and joy of creation I think must necessarily follow with detachment; a distanced, even clinical appraisal.
While I've found this kind of professional detachment also tends to shave the peaks of euphoric highs during development, it's more than worth it by pulling out of the gutting lows. You can be still be passionate and excited about your work without taking the emotional rollercoaster that comes from not being able to separate your work from yourself.
Conducting The Test
[This is assuming you're using what Will Wright calls a "Kleenex tester," a player without prior experience with the game who will likely not test again, rather than a professional or regular tester.]
Make sure your tester feels comfortable enough to talk freely, but do not get too friendly with them. Exerting the social pressures of a new acquaintance (or invoking your friendship with someone you know) means getting polite answers instead of useful ones. People will likely downplay or politely lie to your face to avoid an uncomfortable situation.
I usually start with a very short capsule summary of the game and it's premise (no more than a few sentences), along with any mission-critical info if they they're playing a level that's not the beginning of the game. I also make sure they are able to set any control preferences before they begin (though I don't know why we tolerate your kind, EDSFers. Go back to the Moon.)
Then it's time to prime the tester to think outloud. I'll say something like the following:
"What I'd like you to do is say anything that comes to mind while you're playing, things like "I'm frustrated," or "this part is cool." Don't worry about offending me. If something is really bad you're doing me a favor by mentioning it, it'll help make the game better. Ask questions if they come up while you're playing, or if something isn't clear say so and I'll respond to everything--but after the test is over. While you're playing just enjoy yourself, pretend I'm not here."
Be very aware of how much physical positioning factors into the tester's comfort level. Grab your notebook and sit several feet back, as far back as you can off to the side and well outside their peripheral vision. Making sure they don't feel like you're hovering is important--nobody likes that feeling, and testing can already feel a little weird for most people already. Giving the player headphones can also help them feel less self-conscious. You can still come up and fix a show-stopping flaw or restart the level as necessary, but generally try to make yourself invisible for the duration of the test. You're there to observe.
Slow Motion Trainwreck
And here comes the hard part. Now you get to see all your brilliant plans laid to ruin as what you thought was simple and straightforward to the player is anything but. Try to take it in stride; now when I playtest I almost feel like a classic Freudian analyst, or a scientist regarding a lab trial. Clinical detachment is useful here.
Once the level is out of your hands there's nothing you can do to help it if something goes wrong. So if during the playtest something does happen (such as the surprisingly common scourge of "player error"), short of a crash or other complete show-stopper, you're just going to have to grin and bear it. This can be one of the most punishing aspects of a playtest but this is your lot. What's hardest to take often ends up the most useful information.
So pay close attention. Get impressions down immediately, but make as many notations about specific problems as you can. Missed cues, objectives that are ignored or unseen, key dialogue that doesn't seem to be heeded, horribly unfair firefight, collision problems, the player wandering off the map--all of the above might happen in a single test.
This is your chance to see your world through someone else's perspective, so keep your eyes on the screen and write down any comments they make. Make a mental record of where they're looking--if there's an important element that never crossed their sightline, why or how did it happen? Did you misjudge the clarity of your layout?
As we talked about in the previous LDP article, no one tester's word is law, their experience necessarily represents just a single small data point. Yes, a single test can reveal a lot of issues that obviously should be fixed, but generally speaking you're looking for patterns from multiple sessions; reworking too much based on a single test can be very counter-productive. Balance your observations with instinct.
***
Regular testing will likely result in a greater knowledge of your own bias/hyperawareness of the level. What you feel like is "really overdoing it" might just be noticeable to the player, and the touches you consider "subtle" will probably escape notice entirely.
So test early, test often--it will get easier, and you'll have to redo so much less work if you get playtesters in at the earliest opportunity. Your sense of what works and what doesn't will naturally sharpen. You'll find yourself building level elements that anticipate typical player behaviors, rather than having to come and fix them after a test.
