Tuesday, February 16, 2010

Multiclassing

By now, you should be pretty comfortable on most kinds of testing projects. You might have a couple of weak spots here and there; you might not be the best speller, you might have a hard time organizing your repro steps, or you might just have trouble getting through whichever game you're assigned to. But those are all things you can work on as you go.

So what's next? You can do your best and wait to get promoted, but what else can you do in the meantime?

Finding bugs day in and day out is the core job of a tester, but there are ways to branch out within that. I'm talking about specialties, skills not all testers learn or use, but are nonetheless essential to a quality product. Skills like:

Localization. The word "localization" has several meanings, all of them related. It can mean "general proofreading." It can mean "translation into other languages, and proofreading those translations." Or — this is the definition most RPG fans use — it can refer to taking an awkward, literal translation and rewriting it into something that carries the same meaning, but sounds more natural.

Whatever the definition, a localizer specializes in maintaining the quality of a game's text, and can make the difference between a clean presentation and a sloppy one. Needless to say, the more text-heavy the game, the more important the localizer's job becomes. On especially text-heavy games, such as long RPGs, publishers may conscript entire teams of localizers to check the script line by line, both on paper and in-game, and make sure that each line uses correct spelling/grammar/punctuation and fits in its intended context.

Obviously, a localizer needs a strong command of the language in question. You'll need to know not only how to identify typos on sight, but the technical reasons they're considered typos. (You won't necessarily have to know all the techincal rules right off the bat, but learn them quickly as you go.)

For example, say you come across this line in game:

Look out John!

What's wrong with it? One thing: There needs to be a comma between "out" and "John." Why? Because, in this context, the word "John" is a direct address, a word or phrase referring to the speaker's intended audience. A direct address, by the way, doesn't have to be someone's name; other examples of direct addresses include, "Face me, boy!" "Excuse me, sir..." or "My fellow Americans, I am not a crook!" In all such instances, the rule says to put a comma there to offset it from the rest of the sentence.

So when you're fixing "Look out John!", don't just say, "Add a comma before 'John.'" Say something to the effect of "Add a comma before 'John' to offset the instance of direct address."

Not everyone will understand the technical wordings of the rules you cite, but they'll recognize that they are rules, and that you know them; that helps your credibility.

Here's another thing about localization: Depending on the project, you might be on a short leash or a long one when it comes to making changes. Your instructions might be to make the bare minimum of necessary fixes to the punctuation/grammar/spelling and leave it at that, or you might be allowed to completely rewrite the text wherever you see the need.

Be warned: It can be frustrating to see a horribly-written (but techincally grammatically correct) line and not be allowed to fix it. Your lead can sometimes convince the higher-ups to approve that kind of fix, but sometimes not, especially if the line's already been voiced over (in which case it's pretty much locked down). And even if you're given more freedom to suggest broader edits and rewrites, they may or may not take those suggestions. Still, when everything does come together, it's a rush to see your own lines right there on the screen, especially if they end up voiced over; those'll be your lines the actors are speaking, and that's a great feeling.

Whatever the details of the assignment, be aware of how much freedom you're allowed, and try not to overstep your bounds without at least going through your lead first.

There's much more to say about the finer points of localization, but we'll save the rest for later.

Compliance is another specialty available to most testers. Some places call it Standards testing or Guidelines testing, but it's all the same; a compliance tester makes sure that each title follows all the rules laid down by Sony, Microsoft, and/or Nintendo (depending, of course, on which platforms the title's intended for).

In a nutshell, each of the Big Three has their own sets of rules for each game released on any one of their platforms. These rules deal mainly with how the game software interacts with the hardware; for example, if the end user pulls out a memory card in mid-save, there are specific rules on how the game has to deal with it. The details of the rules are always in flux, but your company should have the all the latest versions of them, usually in the form of a checklist.

Some places consider compliance testing a specialty, and will section off a certain group of testers to focus on compliance full-time. Other places are less specific; each time they want to sweep through the compliance checklist, they might have the lead pick out a couple of testers to do it, and the lead may or may not pick the same ones as last time.

With that in mind, not every tester needs to be familiar with first-party standards, but it certainly does help get you noticed. Even if you're not a designated compliance tester, knowledge of the standards can help you notice potential compliance issues, which you'll then (usually be allowed to) bring to the compliance team's attention.

On the plus side, becoming a compliance tester can make you more valuable, and thus make your job that much more stable. Testers who demonstrably know first-party standards backwards and forwards are a rare commodity, and worth keeping around whenever possible.

There are two downsides to specializing in compliance. One, you run the risk of getting pigeonholed; a company that needs you to run compliance checks on all its titles may not let you spend much time on anything else. Two, there's a lot of pressure. The reason good compliance testers are valuable is because, when it comes to first-party guidelines, even one failure to follow them can get a game delayed for weeks or even months. When that happens, and it will happen eventually, people get pissed. At you.

Now, wise producers and QA leads know that games do sometimes fail first-party guidelines; no matter how well your compliance team knows the rules, someone at one of the Big Three may have a wildly different interpretation of some obscure rule, and call foul when you never would have. Since there's no guarantee of getting it right the first time, no matter how good your team is, it's always good to plan on getting it right the second time instead.

Mobile game testing is another specialization your testing house may include. Not every publisher or developer deals in mobile games, but those that do have their work cut out for them; it's up to their mobile QA department to ensure that each game works on every single supported brand of phone, and that can be as many as 100 different brands. Want to be the go-to guy when they need someone to play through the game 100 times back-to-back-to-back? You can be!

The downside there is pretty obvious; you'll have a pile of phones to get through, some more user-friendly than others. You'll also have to learn all-new ways to test each title; mainly, you'll need to make sure each game behaves properly during incoming calls. And not every mobile game is a winner. You might get a little envious of the other testers as they enjoy their next-gen blockbuster while you're stuck on its comparatively scrawny cousin.

On the plus side, mobile teams are generally small, which makes it easier to get noticed, and they can be much closer to the developers than other test teams are, which can give you valuable experience. Ask around to see if either of those two things apply where you work.

Since localization is what I have the most personal experience with, we'll start talking more about that next.

Wednesday, February 10, 2010

Five Ways to Get Noticed

Before long, you'll have settled into your testing job and gotten a feel for the routine. But of course, you want to do more than test for your whole career, especially if you're stuck on a game you don't like. You might have some ideas on how to improve the game, but chances are no one's listening. You want to climb up the chain, get a better view of your surroundings and the opportunities in them.

Of course, moving up requires getting recommended, and getting recommended requires being noticed. That can be tricky, and more so depending on where you are; your department might have five other testers, or it might have five hundred.

Here are some ways to better your chances:

1. Always volunteer for overtime. Some places will "volunteer" you regardless, but if given the option, always say yes. It not only shows dedication and diligence, and earns you extra cash besides, but it also gives you more time to spend with your fellow testers and with your lead. Which brings us to:

2. Make friends wherever you are. Every fellow tester you meet is a potential future contact in another department or field, so establish common ground and a solid rapport with everyone you can. Remember, when it comes time to pick people out for promotions, they'll be looking for people skills as well as testing ability. (We'll talk more later about what makes a good lead.)

Conversely, however, don't spend too much time chatting on the clock. If your bosses think you're distracting other testers from their work, they'll frown on that. On a related note:

3. Work harder than your friends. Your office might be too big for you to stand out as the hardest-working person on the floor — but you can stand out as the hardest-working person on your team. If you find more bugs, accomplish more assignments, and make it clear that you take the job more seriously than they do, you'll get yourself noticed.

Just be aware that there might be a price to pay; if your teammates think you're making them look bad by comparison, they might resent you for it, or you might find yourself in a rivalry with one or more of them. Keep it friendly and casual whenever possible. Don't flaunt your skills or work ethic, and don't criticize theirs; if you're doing a better job than they are, play it down, with an attitude like, "Gimme a sec; I gotta take care of this," or "Eh, I guess I do all right."

Your mileage may vary on this one. No two testers are the same; some are hard workers, while others are blatant slackers. If you're the only one doing your job, while everyone else in the room is watching YouTube, they probably will resent you — but, on the other hand, you'll have your self-respect and the respect of those above you. Choose for yourself what you want.

Closely related to #3 is:

4. Volunteer for special projects. They might need to send someone over to the developers to test offsite, or a pre-alpha (very early) build of an unannounced game might be looking for feedback, or maybe that mystery guy who works in the corner office, and works on games that no one else sees, might need a hand with something. Whatever they need, if you're at all capable of providing it, make sure you're the first to volunteer.

This can get you noticed not only by your own higher-ups, but sometimes by people outside your department; people in marketing, production, and possibly development. It's never too early to start making new friends and learning new things.

If you work offsite, be prepared for long drives, long hours, and extra logistical hoops to jump through; however, the experience of working directly with a developer is worth all that and more. Learn all you can when you're over there — about level design, AI scripting, or anything else anyone will show you — and take the chance to make more friends. One caveat: Don't rush things when you're over there. You're there as a guest, so be sure not to go poking around uninvited.

If they offer you a chance to give feedback, go for it; it's one of the few times, as a tester, when they might — and I emphasize might — listen to your opinion. Be as detailed, thorough, and insightful as you can be with each point you make; be sure to back up each opinion with as many facts as possible. If you have your own ideas, you might be allowed to suggest them, but think them all the way through first; how easy, or difficult, would it be for the developer to implement your idea, and how would doing so affect the rest of the game? Whatever you come up with, be as diplomatic about it as possible; you have a chance to show that you're an observant and creative problem solver, and the last thing you want is for your target audience to take offense.

To give an idea of what separates good feedback from bad, here are some examples:

Good Example: The wall run maneuver looks cool, but there's never any point in the game where the player needs it. As a suggestion, those empty hallways in the Underground Cathedral could be spiced up with pits and platforms to make the wall run useful there.

Whenever you can, open with praise. "I like this, but that could be better, and here's a viable suggestion on how to make it better." Now here's the same suggestion, poorly phrased.

Bad Example: The wall run's useless, since you're mostly just running down those long, empty, boring halls anyway. Maybe if you put something in the halls, like some pits or spikes or whatever, they'd actually be interesting.

A line like that might pass muster in an online review — most review sites expect you to be informal and snarky — but not when you're trying to convince the developers to take your suggestion.

Speaking of suggestions, remember to keep them realistic; use everything you know about the game and what's gone into it to determine if they're realistic or not. (Getting to work offsite with the developers can come in very handy here.)

Bad Example: The game's fun while it lasts, but it feels like it ought to be longer. (Once the player knows where to go, the whole game lasts about four hours.) Would it be possible to add a few more levels?

This suggestion is politely phrased, but not very realistic. If the game's far enough along that you can tell it's too short, there's virtually no chance they'd have time left to add new levels, even if they wanted to. Adding new levels would mean more than just building them in Maya and dropping them into the game; they'd have to invent new content to fill those levels, and redesign the placement of the content they already have. In most circumstances, asking a question like this, even politely, may hurt your credibility with the devs; they'll decide you don't know enough about what it takes to build the game, and may stop listening to you.

Here's a more realistic way to request extending the game's length:

Good Example: The game's fun while it lasts, but it feels a bit short. (Once the player knows where to go, the whole game last about four hours.) Would it be possible to include some sort of bonus content, or extra difficulty mode, for replay value? As a suggestion, the pictures in the "Extras" gallery could be hidden as item pickups the second time through the game, instead of being unlocked all at once after the first time through.

A little cheap, a little quick-and-dirty, but it would give the game some replay value without having to generate much new content. The developers might take that suggestion, and could play around with it and come up with their own ideas for more bonus content in a second/third/fourth playthrough.

It's rare (although not quite unheard of) that the devs will generate new content based on tester suggestions. Most of the time, the ideal suggestions find clever ways to get the best use out of content they already have.

Of course, when you're thinking about what to suggest, think small as well as big; after all, the little things matter too.

Good Example: The hero feels a little too durable in the current build; I walked him into a room, let five Rock Men pound him nonstop while he stood still, and it took them almost a minute to kill him. Raising the monsters' attack ratings, or lowering the hero's HP, would make the monsters more threatening and thus make the game more exciting.

Good Example: The game feels a little too stingy with gold in this build. I needed to play through the first map perfectly, twice, just to buy all six party members the most basic equipment, and that trend continues through most of the game. The exceptions are the mini-Lunar Beasts, which — presumably due to a bug — give out as much gold each as the boss Lunar Beast does. About 20% more gold from most enemies, and less from the mini-Beasts, could improve the game's pacing.

If you just don't find the game fun, think about why. Are the objectives too repetitive? Is the presentation too bland? Is it too similar to games you've played before? Are the controls stiff? Whatever the issue or issues are, how could they be realistically improved? Answer those questions well, and you can improve your reputation with your co-workers, your supervisors, the developers, and potentially the whole office.

Now, depending on how your office is organized, you may have a separate team, or perhaps a lone individual, who works on a separate set of projects and occasionally requests to borrow a tester or two. If you can get their attention, show that you're dependable — and, when necessary, trustworthy at keeping secrets — you may find not only more friends, but a fast track to more contacts and consideration. (As with #3, this might alienate you from your fellow testers if you let it; make sure to maintain your friendships if your job starts to set you apart.)

Show initiative. Offer to help those who need it. If your lead has a lot on his or her plate, ask if there's anything you can help with, and then take the opportunity to impress them. If you finish your assignment early, ask for another one. No such thing as an overachiever, if you ask me.

5. Knowledge is power. You might already be an ace tester, but there are plenty of other things to learn about; first-party (Sony/Nintendo/Microsoft) regulations, FileMaker scripting, tricks with PowerPoint and Excel, foreign languages, and on and on. Learn from older testers about the history of your department. Ask if there are any old postmortems (post-project reports) you can read. Get to know who else is in the office. Who's approachable? Who's worked on what in the past? Who calls the shots? (Don't wander around outside of your department introducing yourself willy-nilly, mind you; rather, bide your time, excel at your job, and learn who you most want to work with in the future.)

If you can, learn which projects are coming down the pipeline, and convince people to let you into the projects you want. Be audacious, but also have the skill and the body of work to back that audacity up. "Hey, quick question: Do you have a team picked out for such-and-such yet? 'Cause you've seen my work on this, that, and the other; I'd be a good fit, and I'd love to do it."

You might not always get what you want. Sometimes the answer will be no, and part of succeeding in the long run is knowing when to hold 'em and when to fold 'em. But another part is building up credibility and goodwill; sometimes you just have to know the right time to call in a favor.

We'll talk more about that later. Up next: Ways to branch out once you've gotten started.

Tuesday, February 9, 2010

You Do Not Talk About Fight Club

So your job's going well so far. You're finding a good number of bugs, and they like the way you write them up. Good deal. Just keep this in mind as you go:

Don't break your NDA.

You're on the inside now. You know things about upcoming games that almost no one else knows. You might be tempted to tease your favorite message board with the promise of a spoiler or two, or to anonymously leak out a screenshot and let people try and figure out which game it's from.

Or maybe you see people bad-mouthing the game you work on, people who have the wrong idea about what's in the game, or imagine that it sucks when you know it doesn't. Maybe you want to put them in their place, or maybe you just want to gently nudge them toward a more positive viewpoint.

You might be mad at your boss, or at the company, and want to blow off steam, tell a funny story about how your boss dropped the ball. Hell, you don't have to name names; just let everyone know what a jackass he is.

Or sometimes, you just want to strut your stuff, impress people with a hearty, "Hey, guess what game I'M working on!" or, "Guess who I work for!"



When you're hired, you sign a contract not to discuss the company or its products outside the office, and they take that damn seriously. If you leak anything, they will find out it's you — believe me, they have ways — and not only will you lose your job, not only will you be blackballed from ever working in the industry again, but they'll punish your friends and teammates long after you're gone.

Why are they so harsh? They have their reasons.

If you present yourself as one of their employees, without their authorization, you're representing the company, and doing it without permission. (If you explicitly have permission, of course, that's a whole different story, with a different set of rules; more on that down the road.) Even if you have the best of intentions — say you like the game you're working on, and want to help promote it — you can run into PR flaps, and, worse, legal trouble; if someone tells you, "Hey, I've got an idea for that game!" and that idea is something the game already has, or might have down the road, you've got a potential lawsuit on your hands. Usually a groundless lawsuit, sure, but more of a headache than anyone needs, and they'll blame you. (Hint: If, under whatever circumstances, someone pitches you a game idea, the correct response is, "Yeah, sorry; we can't accept game ideas. Legal reasons." If they try to give you any materials for their idea, give them right back.)

Causing any sort of leak will also undermine people's trust in your department, and even in your office as a whole. There was a case a couple of years ago where some jackass at a disc manufacturer stole a copy of a game and posted all the cutscenes on YouTube a week early, ruining the surprise ending. Would you hire that same manufacturer again, if it was your game he stole from? Almost certainly not; even if the rest of the employees are perfectly competent, what he did on their watch undermines them all.

I've seen it happen more than once. I've seen very skilled and useful testers, good friends in some cases, just destroy their own careers — good, promising careers — with one mistake.

Don't break your NDA. And if you do break your NDA, don't break it on the Internet.

What a Bug Needs

However many bugs you find, it's not enough just to find them; you have to report them well too. A bug report, sometimes just referred to as a bug, is a written step-by-step report of a glitch's location, nature, and reproduction process (no, not that reproduction process).

Writing bugs well is crucial for several reasons. For one, people outside your department — and some of the higher-ups within it — will see much more of your bugs than they do of you. To them, your bugs represent you personally, and establish your credibility — or, if they're bad bugs, lack thereof. They might say, "Oh, he just put another bug in. Pay attention; here's what he says..." or, if your bugs are written poorly, "Oh, another one of this guy's bugs. Just ignore it; he doesn't know how to test." By extension, your bugs also reflect on your teammates and your department as a whole, for better or worse.

More than that, a well-written bug will send developers directly to the problem and give them all the information they need, while a poorly-written bug will, at best, be met with more questions, and at worst, send them off in the wrong direction — either way, badly-written bugs waste time.

Before we go into the details of what separates a good bug from a poor one, let's go over the basic bug format. This'll vary from place to place, but here's the general idea.

Most places you go, bugs have three main parts: A title, a description, and a variety of drop-down menus for variables such as location and frequency. Since the variables will be completely different wherever you go (and even vary by project within each department), let's focus on the title and description here.

The title generally starts with the bug's category, followed by a colon, followed by a short summary of the issue. Example:

Collision - Out of World: User's character falls out of world upon dodge-rolling against a specific wall in Chapter 2-5.

(The term "user's character" is used in some places, but not all; others might refer to the player's avatar as "the hero," "the player" — which isn't technically accurate, but it's commonplace — or the character's specific name.)

The bug's description is a step-by-step process. Generally, the process begins by telling the reader where to find the issue, then how to trigger the issue, then what the issue is, and finally what should happen instead. Example:

1) Open Chapter 2-5.

2) Advance to the first museum exhibit and run up against the corner behind the suit of armor.

3) Dodge-roll into the corner at a 45-degree angle.

4) The user's character passes through the wall and falls out of world.

5) The user's character should never fall out of world.

Frequency 5/5.


(Some places, instead of using step numbers for Steps 4 and 5 above, preface them with the terms "Result:" and "Expected behavior:", respectively. Ask your lead or trainer how it works in your neck of the woods.)

Note the frequency above. This represents how many times you were able to make the bug happen, out of how many attempts, beyond the first time you encounter the bug. Some places will have you make five attempts to reproduce the bug, while others will be even more thorough and ask for ten. Not all places will have you put the frequency in the description — some have a drop-down menu for it instead — but wherever they want you to put it, don't leave it out.

Now, what you see above is a clear, solid, well-researched bug. It explains where the issue is, what the issue is, that the issue is specific to that area, how to trigger it within that area, and that it happens every time there.

Here's the wrong way to do it:

Say you're testing an action game, and you crash midway through the third level. The wrong thing to do is to stop testing, hop on the bug database, and enter this:

Crash: game crashes on level 3

1) Open level 3

2 Play game until it crashes

3) Game crasees.

4) Game must not crash


Before you read on, read through that again and count how many things are wrong with it.

The spelling and punctuation issues are obvious. That's important: Spelling counts. If your bugs are full of typos, it hurts your credibility; producers and developers will see your bugs and think, "He's supposed to find mistakes in the game, but he can't even find his own!" Most testers have access to some kind of spell check, so if you need it, use it. Make sure you use full sentences while you're at it.

Not only that, but look at the way the bug's worded. When you say the game "crashes," or any verb in the present tense, you're implying that it happens every time. This bug has only occurred once for the tester so far, so it's wrong to say that. (If you read carefully, you'll have seen another mistake: The bug is missing its frequency.)

And where in Level 3 does the crash happen? Do you have to do anything in particular to make it happen? Does it always happen in the same place, or does it vary from one attempt to the next? Has it ever not happened on this build?

Find out. Before you write it up. Look carefully at each bug you write, anticipate what questions people will ask about what you've written, and answer those questions within the bug itself so that they won't have to ask.

Say you play through Level 3 five more times, and you find out that the crash occurs whenever three or more enemies die at the same time. What's the next step? Write up the bug? "Crash: Game crashes if at least three enemies die simultaneously on Level 3"? No; don't write it up yet.

Can you guess what's left to do? What info you still need?

That's right; check to see if killing 3+ enemies on other levels causes the same crash. It might, or it might not; find out.

Let's say it does. Let's say it turns out that the crash happens anytime you kill three guys at once, regardless of which level you're on. The finished bug, then, would look like this:

Crash: Game crashes if at least three enemies die simultaneously.

1) Open any level.

2) Kill at least three enemies with one blow.

3) The game crashes.

4) Killing three or more enemies at once should not cause the game to crash.

Frequency 5/5


And you see that the finished bug has nothing to do with Level 3; that first version of the bug, above, would have sent the developers on an entirely wrong path. So make sure you find out everything there is to know about an issue before you write it up.

On a side note: Tell the developers how to trigger the bug, but avoid telling them how to fix it; they might take offense. Say you figure out that the reason the game's crashing in the bug above is because the combined visual effects for the three enemies' blood sprays are overtaxing the system. You can say:

3) The game crashes, possibly because the combined particle effects of the enemies' blood sprays are overtaxing the system.

But don't say:

4) The particle effects should be reduced so as not to overtax the system.

Give them all the information you have, but don't tell them what to do with it. (In cases where you believe you have a solution, but the developers don't seem to have found that solution themselves, you can bring it to your lead, who may then pass it along as a suggestion.)

There is, however, an exception to the "don't tell devs how to fix bugs" rule, and that's when it comes to text bugs. Text bugs are formatted a bit differently than most, in that they list both what the problematic line of text currently says and what it should say instead. Example:

Text: Misspelling in Cinematic 3's fourth subtitle.

1) Open Cinematic 3.
[Or, if there's no way to jump directly into a cinematic, tell them to open the latest area before the cinematic, then advance to Cinematic 3 from there.]

2) Advance through the cinematic to the fourth subtitle.

3) The fourth subtitle currently reads:

You fools have fallen straight into my trap! And with you out of the way, there's no one left to stop me! I will rule the wold!

4) Change "wold" to "world", as below:

You fools have fallen straight into my trap! And with you out of the way, there's no one left to stop me! I will rule the world!


An effective text bug needs to do four things: Explain exactly where the mistake appears, quote the problematic line in its entirety, show the corrected line in its entirety, and highlight the correction (either by spelling it out, as Step 4 does above, or by bolding it, if your particular bug database allows that).

Since we're on the subject of what information a bug needs to convey, you might be wondering, "Is it possible for a bug to say too much?" The answer is, "Sort of; it's possible for a bug to have too many words."

Here's an example of an overly-wordy bug:

Graphics: The third column on the left side of the place where the ghost boss first spawns in in the second half of the mansion level gets flickery when the player sees it from the north side of the room.

1) Insert version 100203 of the "Battle Spirits" game into an Xbox 360 console.

2) Turn on the console, highlight "Battle Spirits" under "My Xbox," and press the A button to boot the title.

3) Press Start at the title screen.

4) Advance to the mansion level.

5) Defeat the hound boss in the courtyard, then go through the green door.

6) Take the upper path, turn the gold wheel clockwise one full turn, and then turn it counter-clockwise 180 degrees to open the gold door.

7) Advance to the ballroom and meet the ghost boss.

8) When the fight with the ghost boss begins, stand on the north side of the room, then turn around and look to the right.

9) Notice that, if the player stands on the north side of the room, then faces the third column to the left of where the ghost boss first spawned, the column gets flickery.

10) The third column to the left of where the ghost boss in the mansion level first spawns in should not be flickering.


Now, you probably get the idea, and this is an extreme example, but here's the point: A well-written bug conveys all needed information in the fewest possible words. This bug is three-quarters fluff. Let's go through it again, line by line, with comments in bold:

Graphics: The third column on the left side of the place where the ghost boss first spawns in in the second half of the mansion level gets flickery when the player sees it from the north side of the room.

Everything from "The third column" to "the mansion" could be shortened to, "The third column to the left of the mansion ghost boss' spawn point". Half the words, all the information. (The shortened version does omit the reference to the "second half" of the mansion level, but if there is just one ghost boss in the mansion — which, in this case, we'll say there is — then no need to specify that.) Likewise, the second half of the sentence could be shortened to, "flickers when viewed from the north."

1) Insert version 100203 of the "Battle Spirits" game into an Xbox 360 console.

2) Turn on the console, highlight "Battle Spirits" under "My Xbox," and press the A button to boot the title.

3) Press Start at the title screen.


You don't need to tell the developers, or other testers, how to turn the game on. These three steps can be cut entirely.

4) Advance to the mansion level.

Unless the bug specifically only happens if you play from the start of the game — which, for graphical bugs, is extremely rare — this step can be changed to "Open the mansion level." The difference is that "Advance to" implies the need to start from an earlier point in the game (usually the beginning, if there's no other context) while "Open this level" tells the reader that it's okay to use a debug function (usually a level-skipping function) to get there faster.

5) Defeat the hound boss in the courtyard, then go through the green door.

6) Take the upper path, turn the gold wheel clockwise one full turn, and then turn it counter-clockwise 180 degrees to open the gold door.

7) Advance to the ballroom and meet the ghost boss.


These three steps don't tell the reader anything except how to get to the ghost boss, which any tester or developer should already know. (A new tester might not know, but the bug database is not the proper venue for a walkthrough. That's up to the lead and the developers to provide — or, if they're busy, more experienced testers can help the newer ones in that regard.) Now, if the bug is conditional on doing something in a prior location, then mention that for sure. In this case, though, we can lose these three steps and not miss a thing.

8) When the fight with the ghost boss begins, stand on the north side of the room, then turn around and look to the right.

9) Notice that, if the player stands on the north side of the room, then faces the third column to the left of where the ghost boss first spawned, the column gets flickery.


There are three things wrong with these two steps. One, they're both too wordy. (General rule: You don't need to use the words "Notice that" or "Observe that." "Your shoelace is untied" conveys the same information as "Notice that your shoelace is untied," and does it more efficiently.) Two, the bug isn't consistent with its directions; it uses "north" sometimes, but then "turn around" and "left" at other times. Are we talking about the ghost's left? My left? Before or after I turn around? Three, Step 9 makes the mistake of combining the "how to trigger the bug" steps with the "what happens once you trigger it" step. The first step here should be a short summary of where to look, and at which angle, and the second should briefly describe where the flickering occurs.

10) The third column to the left of where the ghost boss in the mansion level first spawns in should not be flickering.

This one's borderline-acceptable as-is, but since you've already specified which column we're talking about, you can just say "This column should not flicker." Notice also that "flicker" conveys the same info as "be flickering," and more economically; keep that in mind for all present-tense verbs when you're writing bugs.

So the edited version of that bug would read:

Graphics: The third column to the west of the mansion ghost boss' spawn point flickers when viewed from the north.

1) Open the mansion level.

2) In the ballroom ghost boss' room, move to the north wall, then turn around and view the third west-side column.

3) This particular column flickers from this angle.

4) This column should not flicker.


We've gone from 204 words to 56, and haven't lost anything but fat. All of the necessary info, none of the clutter.

And remember, clutter can do more than slow the reader down; if you include steps that aren't necessary to trigger the bug, it can mislead them into thinking that those steps are necessary, and waste their time trying to figure out what it is about those steps that makes the bug happen.

We'll talk more about editing text later, particularly as it relates to other aspects of the job. For now, these few examples should give you a basic idea of how to conduct and organize your bug research. Keep your bugs clean, thorough, and to the point; your lead, your producer, and the developers will thank you.

Friday, February 5, 2010

Types of Bugs and How to Find Them

Your first week on the job is a crucial one. You might be new at this, but they'll be watching you very closely; they'll want to find out (1) how fast you learn, and (2) how good you are at finding bugs.

So of course, it helps if you start off knowing what you're looking for. This post is a general catalog of what kind of bugs are out there, and how you can go about finding them. (As for what to do once you've caught one, that we'll go over in the next post.)

Before we get to that, though, remember: Most of the time, the question you're paid to answer isn't, "What could be better?" It's, "What isn't functioning as designed?" We touched on this earlier, but they want to know how functional the game is, not how fun.

Occasionally, they might ask for your feedback, and that's when you can express your opinions and make suggestions. Just be diplomatic about it; developers take a lot of pride in their work, and an unkind or poorly-chosen word runs the risk of offending them. It's important to maintain good relations with other departments and teams, so even if you think the game is terrible, be polite and constructive about it, and keep in mind which suggested improvements are realistic and which aren't.

But that's on those occasions when they specifically ask for feedback. At all other times, you're strictly there to tag things that don't work. "The final boss' fire attack does no damage" is a legitimate bug; "The final boss fight should be more exciting," while it might be true, is not a bug for a tester to write. Leads and project leads, who've built more of a personal rapport with the higher-ups (and, sometimes, with the developers themselves) can sometimes get away with writing up those kinds of suggestions, but testers shouldn't try it, at least not without asking first.

Visual bugs

You'll see a wide variety of animation bugs. These can range from the blatantly obvious, as when a character freezes in time or thrashes around at crazy angles, to the more subtle, such as when a character momentarily blinks in and out between animations, plays the wrong animation at the wrong time, or faces the wrong way. In games where characters lip sync to the dialogue, the lip movements can be off (sometimes a little, sometimes a lot; you may see characters not move their mouths at all, or lip sync to the wrong line).

Animation bugs aren't just limited to characters. Objects in the environment can exhibit animation issues too; think of a rockslide, where the boulders tumble down, roll to the end of their paths, and then magically reappear back at the top of the hill. Or where the rocks don't appear to tumble at all, but your character still takes damage from them. Think of a cycling animation, such as that of a fire or a waving flag, where the object reaches the end of its animation, then loops back to the wrong frame, creating an awkward skip. Examine each object carefully, and make sure it moves the way it's supposed to under all circumstances.

Another common way to cause animation bugs is to interrupt cutscenes at awkward times. When the cutscene ends, do the characters appear in their proper places? Are there any leftover props or characters who shouldn't still be there? Hit the skip button at various times — just before, during, and just after every major action in the scene — to make sure everything's kosher. Dying just at the moment a cutscene starts is another good way to trigger bugs, if you can pull it off.

Note that animation bugs are not the same as AI bugs, which deal more with NPCs' goals, and how they attempt to achieve them, then which of their scripted animations they display while doing so. AI bugs are covered under "Gameplay bugs," further down below.

Closely related to animation bugs are clipping, or collision-related, bugs. These come in several flavors, ranging from mild to severe.

A game with customizable costumes, hair, or facial structures might have issues with one piece of equipment awkwardly overlapping another. Hats/helmets and hair are notorious for that, especially when the player can modify the size and shape of the character's head or body. Try all possible combinations, and see just how messy things can get.

Also on the subject of equipment, games with elaborate character animations don't always take the character's gear into account. If a character puts a hand to his chin, only to have the hand pass right through his armor on the way, that's a bug. Likewise, characters of a non-human size or shape tend to run into similar issues; a character with big arms and legs is more likely than most to put a fist through his own knee or some such.

Of course, characters can clip through not only their own bodies and gear, but also through pieces of the environment (and in this way, collision bugs are both visual issues and gameplay issues). Have any movable characters — either playable characters or pushable/escortable NPCs, along with any moveable objects — press up against all sides of every obstacle in every area. Chances are you'll find at least some combination that results in solid objects passing through one another.

The reverse is also true; sometimes invisible walls will stop characters' movement for no good reason. (Some invisible walls are there by design, but depending on the title, you may encounter many that are there by accident.) If these invisible walls are reasonably close to nearby obstacles, that's one thing, but an invisible obstacle in the middle of nowhere is something else entirely, especially if you're in a game where hitting a wall is dangerous.

Now, because of the various ways in which character models and environments are built, not every collision bug is easily fixable. If you find that your character's hand passes through the tip of a tree branch when he faces a certain angle, ask your lead whether or not your particular office considers such things worth bugging. (You'll hear the phrase "ask your lead" quite a bit in the posts ahead, for three reasons: One, they generally have the most comprehensive knowledge of the game, two, they'll usually have encountered similar questions in the past, and know the best answers, and three, individual offices will vary in policy when it comes to what is and isn't buggable, and at which stages in the project.)

But some collision bugs are big enough to be written up wherever you are. Ever played a game where you fell through a floor, or walked through a wall, or even rose through a ceiling, and ended up in some single-color void? Those are sometimes called out-of-world clipping bugs, and they should be found and fixed whenever possible. They're especially prevalent in games where characters have a quick "dash" or "roll" maneuver; try all such maneuvers against all obstacles, and see if it gets you anywhere you shouldn't be.

A closely related type of collision bug is one where an obstacle should prevent the player from advancing, but doesn't. If a character is supposed to chop down an obstacle, defeat all enemies around the obstacle, find a key, or whatever, it defeats the whole point if he or she can find a way to just pass right through it.

There are other types of graphical issues as well. Common bugs include characters and objects becoming invisible (particularly common if you move past them, then backtrack through the level and look at them again — and more likely to happen if you die and resume/reload/respawn somewhere along the way), flashes of visual corruption (usually in the form of a multicolored mess, sometimes accompanied by debug text; occurs most often during scene transitions), and issues with particle effects (any visual effect made up of smaller effects, such as sparks, smoke, water sprays, or magic) not appearing or behaving correctly.

Depending on the game type, you may also see many issues with the camera. We've all seen camera bugs before; the most common ones are the times your view gets obstructed behind a large, opaque piece of terrain. It's also possible for the camera to get stuck, or to zoom inside a character's head and display his or her face from the inside. Sometimes you can put the camera through a wall and send it out of the game world, revealing the empty space outside the level geometry.

In principle, finding camera bugs is fairly simple. In games with a user-controlled camera, just go everywhere, and have the camera point in every possible direction from every possible distance. Of course, in practice, that's usually a lot of three-dimensional space to cover, and sweeping an area thoroughly for camera bugs can take time. If a game includes events that suspend camera control, make sure to place the camera everywhere possible before those events occur, trigger those events at awkward times, and then — if possible — immediately trigger them again.

Games with fixed cameras can exhibit camera bugs too. For example, if the game cuts to a top-down view of your character's body when they die, have your character die under a low ceiling and see what happens. If a fixed-camera game includes a multiplayer mode, have all players run in all directions at all times and see if the camera can either keep up or restrict them properly.

Almost any game you'll see will include at least a few text bugs, and there'll be a whole separate section on those. Misspellings, incorrect punctuation, and poor grammar often abound through the scripts of early builds — especially if the developers aren't native English speakers — and fixing them is usually up to you. Just make sure you know how to fix them properly; it does no good to replace one mistake with another.

Keep an eye out also for text that overruns its onscreen borders. Characters' lines can overrun their dialog boxes, and bits of info on status screens can overlap or run outside their windows. If you can catch and bug all such issues, your game's text will look clean and professional, and you'll look good for having been the one to do it.

One other note on the subject of text: In games that include subtitled, voiced-over dialogue, you'll see sometimes that the text and the voiceover won't match. When this happens, the voiceover always wins, and the text should be changed to match it. Why? Because changing a line of text is as simple as opening up a file and typing in a correction. Changing a voiceover requires renting a studio, hiring a director, hiring an editor, scheduling the actor for another session — that's if they're available — re-recording the line, processing the recording, and then adding it back into the game.

(There are very occasional exceptions to the "voiceover always wins" rule, such as if a voiced-over tutorial gives the player incorrect instructions, or calls another character by the wrong name. In such cases, they may simply end up cutting the voiced-over line rather than re-recording it.)

Audio bugs

It goes without saying that quality sound is nearly as important to the game experience as the visuals are. To begin with, test all the sound settings on all the available TV types and sound setups you can. If the game is supposed to support surround sound, or anything higher than stereo, make sure you test that too, both with proper and improper equipment. And don't neglect mono; if possible, make sure you play through the game repeatedly in mono just to make sure nothing gets lost or garbled.

If you hear any sort of screeching noise at any point, or if the game goes silent when it's not supposed to, those are obviously bugs. But there are subtler types of audio bugs too. Listen to hear if anyone's voiceovers get cut off inappropriately, or if two of a character's voiceovers play at the same time. Make sure the right voiceovers play at the right time; simply put, characters shouldn't cheer when they lose. And make sure each voiceover comes from the correct character; if an NPC talks in a high-pitched sing-song voice for one line, then switches to a low southern drawl for the next, you've got a bug on your hands.

Of course, the subject of audio bugs covers more than just voiceovers. Make sure each sound effect plays consistently, and on cue. Make sure that triggering multiple sound effects and voiceovers at the same time doesn't interfere with the music — and on the subject of music, make it change back and forth between tracks as much as possible and see if that causes any issues.

How many variations on your average sound effect does the game include? Do footsteps always make the same sound, or does it depend on which surface you're walking on? If it's the latter, walk across all surfaces and make sure that each footstep on each surface sounds appropriate. Are there different sound effects for individual gunshots, explosions, or menu clicks? Make sure to trigger them all, under all possible circumstances, and see if any one of those variations causes any issues.

When it comes to checking for audio bugs, the key word is noise. Make as much as you can, and see what comes of it.

Gameplay bugs

For QA purposes, "Gameplay" refers to bugs that not only look or sound bad, but get in the way of the user's progress (or speed it along unintentionally).

The most obvious types of gameplay bugs are the crash and its close cousin, the hang. (The difference between the two is that a crash outright freezes everything, including the music and animations, while a hang might let the game continue on visually, but prevent any further interaction — i.e., you back out of the character menu, your character keeps standing there, the music keeps playing, and the next menu never loads.)

Crashes and hangs have all kinds of causes, some of them difficult to pin down. The cause can be as simple as one incorrect line of code; a line of dialogue might include an incorrectly-written command to call a variable, for example, or a script might refer to a voiceover file by the wrong filename. In early builds (versions of a game in test), you'll often find that some parts of the game just aren't finished yet, and if you play ahead of where the developers have gotten, you'll crash that way. (Usually, the developers will send notes, referred to as build notes, on which parts of the game are and aren't ready yet. You can ask your lead if there are any build notes for your current version of the game.)

Simple crashes are usually easy to trigger. Just get to that one part, trigger that one event, access that one menu option, or what have you, and if the game crashes there every time, you've got yourself enough to go on. But many crashes have more complicated steps, and require a combination of circumstances in order to make them occur. Get to that one part — with that one character. Trigger that one event — before you turn in that other quest. Access that menu option — after you access those five other menu options, in this specific order. And so on. Crashes can be so elaborate that it gets very difficult to pin down their causes, and a very few crash bugs may have no repeatable causes at all; in some builds, particularly early ones, just playing the game long enough can make it crash, but "long enough" might range from an hour to all day and then some, with no consistency as to when or where.

In situations like that, when you're dealing with tough-to-reproduce crash bugs, a good idea is to compare each instance of the crash bug you and the other team members have found, find out what they have in common, and use that as a basis for further experiments. (There'll be more on in-depth bug research in the next post.)

Crashes are definitely some of the most severe bugs, but a bug doesn't have to a game-breaker to be considered serious. Enough minor and moderate bugs can ruin a gamer's experience as easily as a crash can.

Think of how frustrating control bugs can be. Just try to remember how many times you've thought (or screamed) "I was blocking!" or "I pushed jump!" or "I didn't click there!" When you're testing, click there. Click everywhere. Try all combinations of buttons under all circumstances, and you'll find at least a few things wrong. Especially in multiplayer. Especially if you start making a conscious effort to stress the game, like by swapping controllers in and out of various ports willy-nilly. (Granted, you can make a case that someone who tries that hard to break a game deserves to see it broken — but still, bug it up.)

Speaking of stressing the game, make sure you check for framerate issues. We've all seen games slow down; not as much these days, but it does still happen. See how busy you can cause the game to get — a favorite method is by provoking all kinds of enemies, then having all of them chase you at once, on-camera — and try to make the framerate drop. (If so, how badly does it drop? Mention that in the bug report.) Framerate drops can be a minor annoyance, but they can also be killers if they happen in the middle of a crucial mission.

Which might remind you of that one escort mission. The one where you almost made it to the end, and then the guy you were escorting went all Leeroy Jenkins on the enemy horde and got himself killed. And then you reloaded, and he decided to press his head up against your machine gun while you were firing. And then you reloaded again, and he just wouldn't move at all.

Yeah, AI is a fragile thing in most games, easy to break or exploit. Test the limits of both friendly and enemy NPC intelligence to see how many ways you can fool them. Position NPCs in front of obstacle courses, and see if they can navigate through them. Provoke friendly NPCs by attacking them, and see if they respond appropriately. (In some games, it might be okay if they stand there and die, but nothing out-and-out strange should happen.) Damage dead bodies, including your own, and see if they get back up to die again.

Remember, you're looking for bugs that make the game too easy as well as bugs that make it too hard. Do enemies frequently blow themselves up with their own explosives? Do they waste all their ammo trying to shoot through walls? Do they stop chasing you, and stand still, if you get far enough away? Bug it all.

Speaking of difficulty, another key aspect of any game is balance. Depending on the project and policy, you may or may not have much say in how difficult or fair the game is, but if you do, use your voice to its fullest. Is a level significantly easier than the one before it? Are the final boss' attacks unavoidable? Does some random NPC have more hit points than the final boss? If you're allowed to — and check with your lead first — then bug it.

Closely related to balance is the possibility of exploits; ways to work the system and win easily. Multiplayer veterans know this category well; they've seen players fight dirty by abusing holes in the level geometry, tricking the game into making them invincible, using weapons in ways they were never designed to be used, and so on. Some exploits require quick combinations of button presses, while some are more about positioning your character in awkward, out-of-the-way spots or playing with the menu interface (think of every item duplication trick from every old RPG).

Sometimes, exploits come not from pulling improbable stunts in-game, but from oversights in the design. Is that talisman much more powerful than the devs intended? Can you find infinite recharges for your one-shot superweapon? Can a certain character's special ability combine with other spells or items to make the character invincible? Bug it.

In games with modular characters, make sure you try every combination of character stats, abilities, and equipment. If any one combination trounces all other combinations, especially in multiplayer, bug that too.

And while you're checking the stats and equipment menu, go over the game's interface with a fine tooth comb. Make sure you can get from any menu to any other menu at any time without any incidents; common bugs of this type include menus refusing to disappear, popping up at inappropriate times, or getting the player stuck. Feel free to mash buttons on the menus while you're at it; that can cause problems too.

And before we get off the subject of statistics, that's a whole category of bugs right there. Make sure each stat tracks the player's gains and losses accurately, no matter how high or low the numbers go. If you max a character's stats out — and you know some players will take the time to do that — do they stay maxed out, or do they roll back to 0? What happens if you try to buy an item you already have too many of, or if you try to buy something more expensive than you can afford? If there's more than one display for a given stat — say, if multiple pages of the status menu display the player's gold — are all those displays on the same page at all times?

While you're checking continuity in the menus, make sure you check it elsewhere too. Does the character's equipment stay the same (barring instances when there's a reason for the change)? Do the villagers' lines still make sense after each story event? Watch the dialogue closely; do characters ever refer to events they have no way of knowing about, or describe events incorrectly? If you switch costumes in one scene, does anything force the costume to change when it shouldn't? Do dead characters ever reappear later? We'll talk more about continuity as part of a later post.

When all else fails, just go crazy. Swap controllers at random. Mash the menu buttons — either the in-game ones or the console menu button — at the most inappropriate times you can think of; during cutscenes, loading screens, while initially booting the game, or loading a save file. Name your multiplayer character an inappropriate name, and see if the game catches it. Use an unorthodox controller; fight the final boss with a dance mat or a set of drums. Switch the options menu around, save it, reload an old save, switch them back, then switch them again. Run all the way to the end of a level, then run all the way back just because you can. Take the time to level up until you beat the impossible boss. Whatever.

All that should give you some idea of what's out there to find, and some of the ways you can find it. Up next: How to write a bug once you've caught one.

Thursday, February 4, 2010

Talking the Talk, Walking the Walk

So you've gotten the call, and they've scheduled an interview. So far, you're ahead of the odds. But needless to say, not everyone who interviews gets hired. It's the second phase of the screening process. (Some places have a third phase, an introductory training session. More on that later.)

All the standard tips for job interviews apply here. Dress professionally, bring a copy of your resume in case they ask to see it, get there half an hour early, greet the interviewer (or interviewers) with a firm handshake, maintain eye contact, show confidence and courtesy, don't bad-mouth any previous workplaces, and when prompted, ask questions about the position. Simple questions, like whether there's a dress code or what the schedule is, can be asked casually. If you ask anything a bit more prying, like what the job pays or what the benefits are, phrase it as if you're asking for a favor, as in, "Can I ask what the job pays?"

That covers the "personality" side of the interview. Needless to say, a good personality certainly helps; if you can charm the interviewer(s), and show them that you'd fit in well as a teammate, you're that much better off than someone who seems nervous or awkward. But it's not enough in itself to get you a testing job, at least not usually.

You also need to know at least the basics of what a tester does, and how they do it. And that's what I'm here to tell you about.

Anyone who's been a gamer for any length of time has encountered bugs before. Think back to some of the bugs you've come across.

Unless you already find bugs for a living, it's likely that most of the ones you remember are the big and obvious ones; we all remember that time the game froze in the middle of the final boss fight, or that stupid exploit that ruined multiplayer until they finally patched it, or — worst of all — that time our save data got corrupted.

But also consider the little ones, the ones most gamers just ignore. Think about that typo in the dialogue from that last RPG, or the time the subtitles showed up at the wrong moment, or the enemy who spawned halfway into a wall and got stuck. Think back to that time you were able to loot a chest twice by clicking it again at the right time, or the NPC advice that doesn't make sense in context. Remember back when that character nodded his head and put his chin through his chest, or the way your new piece of armor kept poking through your old one, or that time the game forgot to draw the background until the cutscene was halfway done?

There's an incredible number of ways a game can go wrong. How many ways can you think of?

Now: How can you make the game go wrong?

An ordinary gamer hates finding bugs. They almost always get in the way. They certainly break immersion, take you out of the experience, remind you you're sitting there holding a controller, watching a TV screen.

A tester wants to find bugs. That might sound obvious, but think about what it means. You're not just playing the game, as a regular player (the "end user") might, until you happen across a glitch; you're going out of your way to cause those glitches. You're stressing the game until you flush those bugs out of hiding, and it's not enough to just make them happen; your job is to figure out how to make them happen consistently.

There'll be a post later on ways to find bugs, but the main guideline is simple: Do the unexpected. Do what the game's developers didn't expect you to do, and didn't plan for. In any game, the "critical path" — the path the end user is most likely to follow — gets the most attention from the development team. So find out where they paid less attention, and poke around there until you find something.

Practice at home before the interview. Or before you apply in the first place. Pick a game. Preferably one you know is buggy, but just about any game will do. Find a bug — it can be a big bug, or a little one — and then find a consistent reproduction process (a "repro") for it. Write the repro down, with instructions clear enough that someone else, someone who hasn't necessarily played the game before, can sit down, read your instructions, and make the bug happen again.

Soon, we'll go into more detail on writing a bug, and we'll talk about what separates a well-written bug from a poor one. But for now, just get a feel for what kind of bugs are out there, and what sorts of ways there are to find them. Then, when the subject of the interview turns to the testing process, you can impress the interviewer(s) by describing the kind of bugs you've already seen.

(Just a note on that last point: When talking about bugs you've seen, avoid discussing well-known bugs, particularly multiplayer exploits. We all know about the Javelin glitch; it's all over the Internet already, and telling them you've seen it won't get you any points. Pick lesser-known bugs, bugs you've found personally, if you want to impress.)

Other tips to be aware of for game-specific jobs:

- They want people who (A) love games, and (B) can pick them apart like a master surgeon. The more you show them both, the better off you are.

- Know the company. Know their games, and their history. Of their games, which one's your favorite? If you haven't played any of them, it might be time to rent, buy, or borrow a few.

- Remember, you may well be up against a dozen other candidates, some of them more experienced than you. What is it about you that makes you the best choice? Come up with an answer. Make sure you convey it to them. And if you can't think of one, build one up before you apply. Don't just BS; it's got to be something you know is true. If you're talented, and you're confident in your talents, show that confidence. If you're not as sure of your talents, build up what you can do. Show them a great work ethic. Learn everything there is to know about their last ten games, and find any bugs that those games shipped with. Have you led an interesting life? Find a way to work one of your best stories into the conversation, and hint at a promise of more.

And "conversation" is a key word here. Don't think of it as an interrogation; think of it as a chance for the interviewers to get to know you, and for you to get to know them. Be professional, of course, but also friendly.

When the interview's over, if you're lucky, they'll hire you right then and there. Conversely, a "We'll call you" doesn't necessarily mean no; it can mean, "We like you, but we have five more interviews scheduled for this one position, so we'll pick the best candidate once we finish with all of them." Feel free to follow up after the first week, and don't assume it's a no until you go at least a couple of weeks without a response.

If it is a no, that doesn't necessarily reflect badly on you; it could just mean that someone more qualified, or luckier, happened to apply when you did. But either way, think up any ways you can better your chances for next time, pick a different place, and apply there. If you hit it off well with an interviewer, that's good whether you're hired or not; you've started building industry contacts.

If you get a yes, then congratulations! You've already gotten farther than a lot of other people. But get ready — whether they put you through a formal training program or have you learn on the job, you're going to have to be a quick study. You'll have to learn what kind of bugs there are, how to find them, and how to report them.

Next time, we'll start covering all that in detail.

Wednesday, February 3, 2010

Gearing Up

Remember when you first sat down with your very first JRPG? Remember the part where you didn't know how leveling or equipment worked, so you just wandered out into the wilderness with your bare hands and a loincloth and got horribly mauled in a comical fashion?

That taught you two lessons: Talk to everyone, and don't go out there until you're ready.

Fast forward to the present. You want to be a tester. You have some idea of what you're getting into, and you decide you still want to give it a shot.

The easiest way to get hired onto a testing team is to (1) be good friends with someone in a position to hire you there, and (2) be available when they have an opening. But since that's not usually an option, especially when you're just starting out, you'll probably have to do it the hard way: Send out resumes.

Familiarize yourself with all the game publishers and developers in your area, and apply to as many of them as you can. Most professions' advisors will tell you it's common courtesy to send only one resume at a time, and wait for a response before you send another, but seeing as how a response can take months (if it happens at all) in this business, I say send them all out at once.

(By the way, for the unfamiliar, developers are the ones who actually build the games, while the publishers write the developers' paychecks, supervise them to varying degrees, and distribute the game once it's done. Some of the larger publishers, though by no means all of them, have their own in-house development teams as well; EA, for example, or Activision.)

Publishers tend to have larger test teams than developers do, so your chances of finding an open position are best with them (though if you're lucky enough to land a gig as a developer's tester, the hands-on experience you earn there can be great for your long-term prospects).

Here's your first big hurdle: Any developer, or publisher, of any appreciable size will have dozens, if not hundreds, of would-be tester resumes in its pile by the time yours gets there. And those with past professional testing experience almost always get first priority when it comes to calling people up for interviews.

If you don't have any prior testing experience, it'll be an uphill battle just to get your foot in the door. But there are ways to better your chances. Like:

Getting a degree. It doesn't have to be a comp sci degree, or anything particularly game related; not for a tester position, anyway. Getting a degree shows that you can finish what you start, and that's a point in your favor, whatever you major in.

Working on homebrew games. You don't need much technical knowledge to put together a homebrew game (though, if you have any, that certainly helps; put it on the resume too!). In this day and age, plenty of utilities are out there to help creative types make their own games without much coding know-how. RPG Maker (either the console or PC versions, though the PC versions are much more robust), Klik-and-Play (my old favorite), and Multimedia Fusion are only a few of the many these days. Use them to get a feel for how games are put together, what kind of bugs can appear, and how to make those bugs happen on a consistent basis. (If you can also learn to fix them while you're at it, so much the better.)

A homebrew game doesn't have to be a solo project, either; you can sign on with an existing project, especially as a tester (who doesn't want free testing?) and practice that way. Hundreds of communities are out there online to bring homebrew teams together; get out there and join a few.

Proofreading. Proofread your own resume, sure, but also cultivate a skill for proofreading other people's work. Good text editing is a valuable skill for a tester; some games are full of typos, and it takes a knowledgeable proofreader to root them out before the game ships. If you can do that well, you can show that you can find and correct mistakes, and do it in a way that not everyone can do. If you've done it in any sort of professional capacity, such as for an office job or school newspaper, mention that too.

Knowing another language. Being able to edit English well is a rare talent, but if you've got a second language under your belt, so much the better. The worldwide gaming community is growing more tightly knit all the time, and that means that more and more games include multilingual support. For North America, the three main languages are English, French, and Spanish; for Europe, English, French, Spanish, Italian and German. Japanese is another prominent language, of course, and some games also support Dutch or Portuguese. If you can read and/or speak any of those, with at least acceptable fluency, then you've got a definite edge over those who can't.

Getting published. Do you have any published writing out there? Even for school publications, it counts; they're looking for people who can write well, and any publication credits you have point toward that. If anything you've written has won any sort of awards, so much the better; you can put "author of the award-winning story 'Such and Such'" without necessarily having to mention that the award came from your community college.

Developing other office skills. A tester needs to be proficient with Word at the very least (the higher the functions you're familiar with, the better), and may also need experience with FileMaker or Access. A lead tester can make his or her job much easier with some skill in Excel. Get to know as many of them as you can, and practice your typing while you're at it. If you can type over 50 words a minute, mention that on the resume as well.

Having distinctive hobbies. The "hobby" section tends to go last on a resume, or close to it, because it's less important than your work experience and other qualifications. However, it can help to show how creative and talented you are, especially if your hobbies include any kind of music, writing, film, or other such creative endeavors. Active hobbies, such as motorcycle riding or rock climbing, can also portray you in a positive light. The hobby section's minor, but don't neglect it, as it might give you that extra push.

Knowing your line of work. Putting "lifelong gamer," or words to that effect, on a tester resume might sound trite and obvious, but it's still important. If a resume shows no particular interest in games, it's likely to get put aside in favor of one that does. You'll need to know all you can about games in general, and about the company's games in particular.

Now, it's possible that none of the above applies to you. If not, you can send a resume without any of those things, or any prior experience, on it; it does occasionally happen that a company will need people immediately, and will simply hire whoever applies at that moment. But it's rare, and your chances are much better if your resume's got some meat on it. If it doesn't, now might be a good time to learn a new skill or two; nothing says you have to apply for a tester position right now, and the skills above will help you in all kinds of ways even if you end up in another line of work.

Once you've sent your resumes, follow up with each company, about once a week, to make sure that you stay on their radar. It may be weeks or months before they call you, and they may never call at all. But if you do all of the above, you'll maximize your chances.

Of course, getting that call is just the end of Step One, Step Two being the interview. Next time, we'll talk about that.

What to Expect

"Video Game Tester." Sounds like a dream job, doesn't it? Especially when you're young, you love games, and your other career options might be limited. Hell, you could stock shelves, deal with customers, or get paid to play video games all day. Which would you choose?

Well, know what you're getting into first. A lot of movies and TV, from Big to Grandma's Boy, portray the game industry as a place to lay back, toss around ideas, beat your friends at DDR, and then maybe whip up a game every once in a while.

Forget all that. A very few places tried to run their businesses like that, places that took the money from their first hit and built a gamer's paradise. To the best of my knowledge, none of them are still around; they burned through their money, didn't produce enough to bring more in, and dropped off the map.

Before you consider getting into testing, here are a few things to know.

The pay's not great. It's all right, but not great. I've seen testing houses pay minimum wage, and I've never seen any pay more than $12 an hour; keep in mind that's before taxes. And most places hire testers only on a temp basis, so forget about health benefits, or any other kind, for at least your first year, and maybe longer.

Now, depending on the place, you may have the opportunity for overtime. Some places require it. Some places run you ragged with it. On the upside, overtime pays time-and-a-half for every hour in the day past 8, and double for every hour past 12. On the downside, of course, if you're pulling 12-hour-plus shifts, you won't have time for much else, and enough of it can wear you down hard.

I've seen places demand 12-plus hours a day, every day including weekends, for months. Some people throw three months at those kinds of jobs, make ten grand or so, and then take a month off. If you're on your own, that's not bad, but if you have any loved ones, be aware of how much time you might spend away from them.

Promotions have their ups and downs. You can also make a little more, of course, by landing a promotion. The types and numbers of promotions vary from place to place; some go "Tester > Lead Tester > Project Lead (essentially the boss of several lead testers)," while others have a "Senior Tester" rank below lead. For the most part, getting promoted within your testing department is a good thing; it makes you more likely to be noticed, pays better, and brings you that much closer to the possibility of benefits. But be aware of the consequences too:

— The higher up you get, the less you see of the games. Testers spend all day with their hands on the controls; lead testers and up spend most of their time sitting in meetings, organizing schedules, and writing reports about reports about reports.

— As you move up, you gain certain freedoms — most importantly, the freedom to make contact with higher-ups you wouldn't have been able to talk to before — but you also lose some of the freedoms you enjoyed as a tester. More specifically, those freedoms will be replaced by responsibilities; for example, while a tester can usually arrange a day off without much of a hassle, a lead tester has to jump through extra hoops to ensure the project keeps running smoothly in their absence. You'll be expected to stay each night until your last tester has gone home (or until someone qualified can watch them for you), and you'll have to be the first one there in the morning to ensure that everyone hits the ground running every day.

— Generally speaking, testers are too low on the totem pole to notice much trouble higher up. As you start climbing, any office drama will become clearer and clearer, and will get more and more likely to eventually involve you personally.

— On a related note: In this business, pressure and heat come from up above, and diffuse as they move downward. A producer might pressure the head of your QA department, who passes most (but not likely all) of that pressure onto his or her immediate subordinates, and so on down the ladder. As a tester, you only get a whiff of it, but as a lead or higher, you can expect anything up to a full-force gale if things aren't going according to schedule.

— Remember also: Not everyone can be a lead, at least not all at the same time. Depending on where you work, there might be three testers for every lead, ten testers, twenty, or more. Only the sharpest, most capable, and most productive among those testers will be considered for promotion, and that's if there are any higher positions available, which isn't always the case. (And if you get passed up in favor of someone you work with, don't get too upset, at least not the first time. Sometimes, the decision comes down to a coin toss.)

— Lastly, if the company does finally make you a full-time employee, the benefits are usually nice (and, if you need health coverage, obviously necessary). However, when that happens, they may switch you over from hourly pay to salary; that usually means no more overtime pay. You'll get used to it, especially if you need the perks, but at first, it may feel less like a promotion and more like being conned into working for free. If you do end up pulling a lot of overtime, check with your supervisor to see if there are other ways you can be compensated for it. Some places offer extra time off in exchange for the extra time worked.

Climbing up will make you more money, and can put you in a better position to get what you want out of the industry. But you might sometimes look back at the old days, when all you had to do was find bugs, and miss the simple life.

On the other hand...

Testing can be extremely boring. Sometimes, it's great. Sometimes you get your hands on the next big hit, before anyone else does, and not only do you get to play it first, you get to be a part of it.

But that's not what usually happens. You don't have much control over which game you're assigned to. You might not like that game. You might hate it. It might be completely outside your tastes or expertise; you might be the world's greatest RPG guru, but that won't stop them from putting you on Barney Learns the Alphabet, if that's all your department has in test at the time.

You'll play that game for hours a day, over and over, for weeks or months at a stretch. You'll explore every corner of every screen, every variable of every menu, and then do it all again when the next build of the game arrives. And that's assuming that the game's fully playable; you might start off with incomplete builds, or trial versions, or promotional demos, where all you have is some tiny little slice of the game, and all you can do is run through it again and again, looking for anything and everything that could possibly go wrong with it.

If it's a trivia game, you'll learn every answer. If it's an action game, you'll learn to beat it blindfolded. If it's an RPG, you'll know all the dialogue by heart, and spend the day making fun of your favorite scenes with your fellow testers. (Well, that can be fun, at least.) Even if you start off liking it, chances are very good you'll be sick of it long before the end.

And it might not end when you think it's going to. You could be a day away from submission when some new out-of-the-way bug pops up and necessitates redoing the whole last week of testing. Believe me; that happens all the time. You might think it's all over and done with, only for one build on one region to come back into test over and over again, like some undying curse.

You can easily be numbed into not caring, into going through the motions and calling it a day.

Don't be.

The ones who burn out are the ones who stop moving. The ones who get ahead are the ones who keep taking their job seriously, and keep kicking ass at it, even when there's no obvious reason to. Because there is a reason. There's always a reason.

Well, almost always.

If all you want to do is be a tester, that's fine. But you might have another reason for getting into the business, some greater ambition, a dream. Do you want to be the next great designer? Is there a game idea in your head, something you've always treasured and wanted to make real? Hold on to it, and keep fighting your way up if you want a chance at it, because:

Nobody buys game ideas. No, I'm not trying to crush your dream. But here's the reality: Game ideas are a dime a dozen, and there's nobody — yet — who's out there looking for yours.

It's not like Hollywood. In Hollywood, you can write your own screenplay at home, find an agent to help you market it, sell a studio the rights to the script, and then either go home with the cash or, if you're lucky, join them on the set to help make the movie happen. It's a very steep uphill battle, with many more failures than successes, but it does happen, and there is an established market for it.

In the game industry, not so much. You'll never sit down with a game publisher, pitch your idea, and walk away with a pile of money; game concepts just aren't a marketable commodity in and of themselves. Most concepts come from either within the publishers' own offices, or from established developers. Even most of those concepts — about 99%, from my experience — never get off the ground, and among those that do, a significant amount get cancelled in mid-production.

To carry a game concept from pitch to gold master is a phenomenally rare thing. But I've done it. And that should mean that anyone can.

In the posts to come, I'll say as much as I'm contractually allowed to about how I did it, and about how I got into a position where I could do it. There aren't any magic tricks to it; just hard work, good networking, a little creativity, and a lot of luck.

And if you're still interested in being a tester, I can tell you about that too, about how to test well, hone your skills, and get ahead doing it.

More to come soon.

Press Start to Play

If you're reading this, it's because you either know me personally or want to know how to get started in the game industry. This blog is all about my personal experience — without breaking any confidentiality agreements, of course — about how to land your first industry job, and about how to perform it well enough to get ahead.

Since 2004, I've been a game tester, lead tester, project lead (which was the next step up, where I worked), and eventually worked my way up to writing and design, with various other tasks, duties, and privileges along the way.

My experience was an uncommon one — most people never get the perks that I did — and in some ways, I was very lucky. But I also learned a great many things about how to attract that kind of luck, and I'm here to pass that knowledge on.

One rule above all. This is a mantra I invented for myself on my very first day in the business:

To succeed, you must advance.
To advance, you must excel.