Stepping Up

Work as hard, as skillfully, and as efficiently as you can, make as many friends as possible, assist your lead in any way you can think of, and eventually, if things go your way, they just might move you one rung higher.

While sometimes, people do get brought straight up from tester to lead tester, it's more likely that your first promotion will be to lead tester's assistant. Different offices have different titles for that position; some call it "assistant lead," some say "senior tester," and sometimes the senior tester is above the leads. But, whatever they decide to call you, you'll be your lead tester's right hand.

Let's talk about what that does and doesn't mean.

It means you'll have to know your lead's job about as well as he or she does. If your lead's away from his or her desk, whether at a meeting, busy with another project, or home sick, you'll need to be able to keep things going in his or her place. Get your lead's cell phone, home email, and other contact information right off the bat, and make sure they have yours. More importantly, make it a point to learn everything your lead does for the project, so that you can handle it if called upon to do so.

It means most of your work, day to day, will be handling your lead's overflow. Leads have to juggle reams of paperwork, maintain their team's equipment, monitor their testers' assignments, draft plans for future testing, and so on. Anything the lead doesn't have time for will most likely be assigned to you. Some of it may be assigned on a case-by-case basis, and some of it may become your responsibility daily. That's why it's good to be ready for anything.

It means you'll have to be the most reliable person on the lead's team. Be the first one there in the morning, and stay, if at all possible, until your lead turns you loose at night. Complete tasks promptly, effectively, and with a smile. A reliable assistant is a reputable assistant, one likely to move up further when openings appear. An unreliable assistant, not so much.

It also means you'll need to know your title backwards and forwards. Leads don't always have enough time in the day to learn the exact layout of each map, the new features of each build, or the names of every NPC. Since chances are you'll have a bit more free time than they do, use it to expand your knowledge of the game, so that you can answer any testers' questions (or the lead's questions) about it.

It doesn't mean you'll be running things your way, at least not right off the bat. You might be acting lead while the lead is unavailable, but don't take that to mean you're in charge. Stick to what the lead would do, and if the need comes up for an important judgment call, notify the lead as soon as possible and defer it to them when they get back. Make sure you keep the lead in the loop on everything; tester assignments, questions from higher-ups or other departments, equipment needs, and so on.

Eventually, if you build up a strong enough rapport with the lead, he or she might come to trust you enough to let you make bigger decisions. If so, respect that trust, continue to keep him or her in the loop, and if you have any recommendations on how the team might do things better, go ahead and suggest them.

If you end up in a dispute with your lead over how to run things, make your case, but then respect his or her verdict; remember, your main job is to handle your lead's overflow, not to make policy decisions. If you feel strongly enough about a subject that you want to appeal the lead's verdict, there's only one proper way to do it: Request to the lead that the both of you take it to the lead's supervisor and get a ruling. It's a reasonable request; the lead isn't obligated to agree to that, but they should.

Do not go to the supervisor over the lead's head. That's a surefire way to earn a reputation as a backstabber, and can severely damage working relationships and morale. Whatever point you might have to make isn't likely to be worth that.

Conversely, if you're friends with another lead — this is another reason to make friends everywhere — it's generally kosher to talk them about issues with your lead, and ask them for help. Just don't overdo that; as much as possible, keep any disagreements you might have one-on-one between yourself and your lead. That means leaving the testers out of it too, whenever you can; it's usually bad for morale if they see their supervisors in conflict.

Most leads and higher-ups you'll work with are reasonable people — and remember that reasonable people can disagree. Only once in my career have I worked with a completely unreasonable higher-up, and if you come across one of those, my best advice is to do your best job, make sure people can see it, and that'll give you some clout when push comes to shove.

See what I meant earlier, about how office politics get cloudier the higher up you go? Thankfully, most of your job as an assistant won't be about that. Just work to keep your lead happy, do what's asked of you, and you'll enjoy a few new perks, such as:

- Higher pay, usually.
- Related to that, more of a chance for overtime hours. Also usually.
- Your first taste of power in your office. Depending on the office, the rank-and-file testers may or may not technically count as your subordinates now. It can be awkward suddenly having authority over your friends and co-workers. Use whatever power you have carefully and wisely, and always treat subordinates with basic courtesy and the respect they've earned.

(A note here on the difference between courtesy and respect: Courtesy is free. Everyone should always be treated kindly and fairly; that's courtesy. Respect is what you earn for yourself; it's a combination of appreciation for what you do and admiration for the way you do it. And the way to get people to follow you willingly is to earn respect, and to show respect in return for the good things they do.)

One more perk as an assistant: You'll likely gain access to people you wouldn't have met as a tester. People like producers, marketing executives, customer service reps, and so on. Take the chance to make more friends and contacts, and learn all you can about what they do. Don't bombard them with questions, but show interest in their work, and most will be happy to show it off for you. Some of them may ask you for help; ask your lead before you take the time to help them, sure, but if you're not busy, chances are the lead will say yes. And that's great for you; as I'll go over in detail later, favors are part of the foundation for great career moves.

That's all the time I've got for today. Next time, we'll talk about being a lead.

Localization 101

"Use the right word, not its second cousin." - Mark Twain

Localization — here defined as text editing and rewriting for the purpose of a smooth read — is a key component of QA, to the point where some entire offices specialize in it. Whether your assignment is to fix typos or rewrite entire scenes, here are some things to keep in mind.

First, be aware of all the common spelling and grammatical mistakes. We've all been on the Internet long enough to see the confusion between "its" and "it's," between "their" and "they're," between "your" and "you're," and so on. Be aware also of the proper use for each punctuation mark. Don't join full sentences together with a comma, for example; use a period or, if the sentences are closely related, a semicolon.

There are plenty of sources out there for detailed rules on proper grammar, so I won't bore you with those details here. For QA and localization purposes, however, be aware that each office likely has its own rules on how to handle variations in grammar.

English is an evolving and flexible language, with many valid variations on several terms. Terms like "OK," or "ok," or "okay." Some spell it "all right," and some spell it "alright." Interrobangs ("?!") can be written as "!?" as well. Any one of those ways is fine — as long as its consistent.

If Character A says "OK" in one scene, Character B shouldn't say "okay" in another scene. If your written emotes are marked with asterisks and written in lowercase, such as "*smile*" or "*punch*," you shouldn't see any marked "(Sigh)." Your localization department likely has established rules on which variations go where, and if they don't, be sure to ask your lead.

Now, just as grammatical consistency is important, there are other types of crucial consistency, specifically relating to characterization and narrative.

When it comes to dialogue, make sure each character has a distinctive, consistent voice. How formally do they speak? How do they address other characters? Are they friendly? Aggressive? Condescending? Enthusiastic? Analytical? Are there any particular words or phrases they like to use in certain situations? Do they have any particular quirks, such as repeating certain consonants or stumbling over certain words? Do they have any particular nicknames for particular topics or other characters? Are they quiet, or are they talkative? Serious, or do they like to crack jokes? Is there any other specific character they treat with particular reverence or disdain? What makes this character angry? What makes them happy? What do they want?

When, as a writer, you know the answers to those questions, you'll make it come through in their speech, and give them a world of depth in the process. As the RedLetterMedia guy once said, the mark of a well-defined character is one you can easily describe without mentioning their looks, their outfit, their role, or their profession. Take all that away, and what's left is their personality — their voice.

Make sure to vary it up from one character to the next, too. Characters from similar backgrounds may have similar speech patterns, but that doesn't mean they'll have the same personalities — and, if there's a good reason to, they may vary their speech patterns depending on who they're with at the time. One RPG from a few years back had a certain character, a noblewoman, give a fellow noble a formal greeting, then ask, "Can we drop the formality? All this stiffness goes straight to my neck." Showing multiple sides to a character, as long as the characters have good reason to show those sides, can add to their depth immeasurably.

Something else, too: If a character does have a particular quirk — such as, say, responding to requests with "As you wish" — make sure that only that character exhibits that quirk. That'll help keep each character distinctive and memorable.

Now, depending on what you're assigned to, much of this work may already have been done. In that case, much of your job will be to ensure that each character's voice stays consistent from scene to scene. Make sure the game's rough street thug doesn't start speaking in formal terms. Make sure the raging berserker announces his intentions in an appropriately bloodthirsty fashion (unless he's Hannibal Lecter, in which case, make sure he stays calm while devouring people's intestines). If your pirate girl introduces herself by being spunky and flirty, make sure she doesn't start talking like an old wise man when the time comes for her to give exposition.

Ah, exposition. It's a necessary evil — without it, the audience won't know what's going on — but it's always tough to write without being boring as hell. Nothing is duller to a viewer, or player, than watching characters just stand around telling each other the plot. In the worst cases, the characters drop all traces of their personality while they're doing it, becoming blank slates as they recite facts for the viewer's benefit. Humphrey Bogart once said, "Whenever they have me give exposition, I always hope they'll put some camels ****ing in the background so the audience'll have something to look at."

The trick to making exposition bearable is to weave it into the characterization. The first question to ask is, "What does the audience need to know?" But don't stop there. Once you have the answer, ask, "How would these characters describe what the audience needs to know?"

Here, let's have an example. Let's take the exposition in the next paragraph, and tell it three different ways:

16 years ago, there was a great war. Rebel forces with foreign backing slew the king and drove his young daughter and infant son into exile, under the protection of the king's best knight. Unfortunately for everyone, the king's death triggered a terrible weapon, and the resulting blast vaporized most of the capital city.

Now, here's that story told by a random villager:

I haven't had a full night's sleep in 16 years. Every time I close my eyes, I hear that blast... I'm lucky I was out in the Market District. If I'd been at home, I'd be dead, like...like everyone else. Look, I don't care WHO was behind the rebellion; King Phaedren must be burning in hell right now, and I hope the same for his children! Building a weapon like that right here in the city, binding it to his own heartbeat... What was he thinking?

Here it is told by the king's knight:

Do you remember that night, Aria? You came up to my knee back then; I doubt you remember more than the screams, and the blast at the end. I saw it all. The rebels at the gate, pawns of the enemy, clashing with us, burning with us... There were too many of them. Most of us were out in the field, fighting that stupid war. I saw your father's face as they broke through the gate. He knew it was over. He knew what would happen next. That ridiculous bomb; I still can't believe he let them talk him into building it, let alone keeping it here in the city, tied to his own damn heart, the old... Forgive me; I shouldn't speak ill of him. He was my king, and his final order stands: "Save my children."

And here it is told by a veteran of the rebel army:

You know what they say about us rebs these days? About who supposedly backed us and trained us? Doesn't matter. What matters is how many good people died to bring that tyrant down. Never mind how many starved, or died in that bloody war he wouldn't stop waging. No, I mean the men and women who stormed his castle and pierced his blasted heart. Funny; we all thought he was bluffing about the bomb. "If I fall, the city falls." We thought even he was above that. And tens of thousands paid for our faith in his mercy. They say his little brats survived, you know. They'd be about your age now...

Whenever possible, convey exposition as naturally — even as stealthily — as you can. Couch it in arguments, humor, excitement, sex, or anything else the audience can relate to. Make sure the audience gets it, but don't hit them over the head with it if you can possibly avoid it.

Make sure, as well, that the characters' dialogue accurately reflects the events of the story and the circumstances of the setting. Common mistakes include characters who refer to events they have no way of knowing about, or refer to dead characters as if they were still alive, or speak of past events as if they were still ongoing (so once you've cleared out the monsters, make sure there's no one still running around yelling "Monsters are attacking!")

That's all the time I've got for now. Next time, we'll get back into career advancement, and talk about what happens when you reach the next rung on the ladder.

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.

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.

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.

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.