Sunday, May 18, 2008

Work is busy, posts are late

I totally missed last Monday's post. I'm sure all three of you are terribly disappointed.

Why would I miss such an important occasion, you may ask? Well, I'll tell you, and in so doing, give a brief glimpse into the exciting, fast paced, and stupendously glamorous world of video game testing.

One of the harsh realities of the video game industry (along with low pay, no supermodels, and questionable personal hygene) is something called crunch. Basically, it's mandatory overtime during periods close to deadlines. The extent of it varies from company to company, and it can range from soul crushing to something resembling a refugee camp of coders and testers sleeping under their desks and eating nothing but Cup 'o Noodles.

Harmonix crunch is closer to the merely soul crushing end of the spectrum. We work 11 hour days Mon-Thurs, and eight hour days on Friday and Saturday. This goes on for a long as need be. Right now, we're in a light crunch, so it's only going on for two weeks. Crunch, however, flows like the tide, and it can be extended as needed. Last summer, crunch went on for about two months. We're hoping it won't be so bad this time. Hope springs eternal.

So what does one do during crunch? Much the same as one does during non-crunch, just more of it. What's that? Well, let me tell you.

The tester's job is to find bugs in the program we're testing. These bugs cover a wide range of problems and severities. Game crashes completely while starting up? Bug. Is something misspelled in the text of a certain screen? Bug. If you unplug and replug your controller 15 times in a row, and then back in and out of a certain screen while mashing on the green button and unplugging the ethernet cord, and the game freezes? Yup, bug.

Now, the trick is figuring out exactly what you did that caused the bug. Sometimes, it's simple. "Pressing start on the title screen causes crash." That's easy. Most times, it's not that simple. In the last example of the previous paragraph, you have to figure out is it exactly 15 unplug/replug cycles that do it? What if you mash the red button? Does it happen on every screen? So on and so forth. It's actually a lot like running a science experiment where you have to start with a theory about what's causing the problem, and then start eliminating variables.

What this boils down to is a whole lot of repetition. You might spend half a day tracking down a single bug. You might find three other things in the process. Sometimes, it's mind-numbingly boring. It is a good feeling when you finally figure out the exact steps needed to get a bug, and can finally submit it to get fixed.

So that's part of what goes on on a daily basis. A good chunk of the rest of my time is taken up working on test plans and checklists, which are the documents that we'll use to do thorough tests of the game now that it's getting more stable. These fall into the mind-numbing category. An example of a section of a checklist:

1) Load game. Each of the brand screens come up?
2) Does intro movie load?
3) Does intro movie play with sound?
4) Does into movie play to the end with no skips?
5) After intro movie, does title screen load?
6) Does title screen remain up for 30 seconds?
7) After 30 seconds, does demo loop play?
8) After 45 seconds, does game return to title screen?
9) Does pressing start on title screen bring up main menu?
10) On main menu, does pressing up and down cycle through menu items?
11) When a menu item is selected, does it's graphic change appropriately?
12) Does pressing A on a highlighted menu item produce a sound?
13) Produce an animation?
14) Are you taken to the appropriate next screen?
15) Does pressing B take you back to the main menu?

And so on and so forth. The checklists are for "critical path testing", or "what we expect the user to do."
Above and beyond this, we also do creative testing, or "shit the users shouldn't do, but will because they're dumb or are trying to break the game." This can include unplugging the system at weird times, pulling various wires, creating as many data items with stupidly long names as possible, or, my favorite, trying to get around the profanity filter (yes, you totally can).

What you don't actually get to do much of when testing is play the game. Yes, you go into gameplay, but we have cheats entered with a keyboard that can autoplay the game and do various other things that we might need to do while testing. Frequently, you can actually play if you want, but generally, your primary focus isn't necessarily on playing, and your attention is better devoted to looking for things other than gameplay, unless you're actually testing the gameplay element.

So, that's what I spend my days doing. Because of that, I didn't get last week's post up, and I also didn't have much time to game. I'll put up my regular post tomorrow about the games I'm sad I can't buy, and what games I did get to play.

No comments: