I'm really feeling it!

A QA Contractor Survival Guide!

I've been following these recent posts concerning contractor work, especially as it applies to the Quality Assurance field of the gaming industry. Initially I didn't want to say anything, but the more I read the comments, the more I felt inclined to chime in (plus my boss is really insisting I post this).


First let me give some credentials, as to why my opinion on this topic even matters. I've been working in the gaming industry since 1997 when I was twenty years old. The first ten or so years of that time were spent working contract jobs, and all of those jobs have been in QA.

In that ten year period, I went from being an entry level QA Tester, to an Assistant Lead, and finally a full-fledged Lead. Now that wasn't all at one studio, and it wasn't all one happy quick journey. I had a number of basic low level QA contracts even after I made A.L. and Lead. That's the nature of this industry. You can be at the top of the heap in your department, have a contract expire, and have to take the next job that comes along. Sometimes that job is a step back. Sometimes it's better than you hoped. This is a very common progression, and I've met many other alumni of this industry that have similar stories.

I'm writing this anonymously, because even if what I have to say isn't criticizing any particular studio, it's just not a very smart idea to attach one's real identity on an opinion piece, directed at the industry you call home. With that said, here's some thoughts on contract QA work... more specifically how to get into it, and what to expect going in.

First, gain a basic understanding of the fundamental differences between playing a game for leisure at home, and testing a game for a career at work. I have seen countless testers jump into the field, thinking they just found the motherlode: a job where they can screw around all day playing video games, and get paid for it. Suffice it to say, they don't last very long. Or they realize what the job really entails, get with the program, and mature into experienced testers.


Other things that are essential to a future in testing: impeccable spelling and grammar. This is especially true for studios that are based outside the U.S., because those bugs need to be translated, and spelling errors screw that up royally. Grammar is also a fundamental skill for testers, because you are testing products that are just filled with text. An analytical mind is also incredibly important. You have to not only find issues, but be able to piece out exactly what caused them, and explain those steps in layman's terms so that anyone reading your bug report can understand them. This isn't something everyone can do. But if you can, you have a real leg up on the competition. This next one can apply to the analytical thought process, or just about any aspect of your position. But you have to have patience. You have to be willing to sit down with an issue and take the time to properly break it down. This requires tons of patience, and focus. You also have to be patient when it comes to furthering your position at a studio.

Also, be aware of the differences between Publisher QA (i.e. Sony/Microsoft), and Developer QA (i.e. Sucker Punch/Volition/etc). In publisher QA, you are much more of a cog in the corporate machine you'll have little to no say in design/production decisions. You're much less likely to be noticed among your peers, you'll rarely interact personally with the dev team, and you'll probably have more frequent crunch times. But you're also much more likely to have your contract renewed if you kick ass and show your immediate supervisors you are great at your job.


Developer QA is a totally different beast. You will likely get a chance to submit ideas, feedback, and suggestions regarding the design and balancing aspects of your title. You'll work very closely with the dev team on a daily basis, and you'll likely only crunch towards the end of the project. But you're also unlikely to be brought back after your contract, because developers tend to have large lulls between projects, where QA is not needed. Also dev teams tend to hire experienced QA testers with at least one or two projects under their belt.

So with those preliminaries in mind...

Apply for that job. Some good places to look for entry level QA are craigslist, gamedevmap, gamasutra, and other tech focused job sites. The big publishers tend to post ads that make QA look like a "totally awesome fun job playing games for money". Don't be fooled. This is a job, yes it can be fun if you let it be, but at the end of the day it is what you do to pay your bills. And your work is saving your employer millions in lost revenue, by hunting down and killing as many defects as you can find.


Now before you apply, do a little research on the studio you are looking into (a lot of times, contractors aren't told which studio is hiring by the temp agency, so this isn't always an option). When you do apply, make sure that your application is clean and well written (you probably won't have a resume at this point). Most big publishers give all new hires a grammar/spelling test, so be prepared for that too.

If all goes well, you'll get an interview with the hiring agency (note: this is an entirely separate company from the site you will be working at). I'm not going to get into interview tips too much (that's an entire article on its own). The agency interview is usually very brief, and is there to weed out the really unfit candidates. When you pass the agency interview, you'll be given a second interview with the studio in question. At entry level, most interviewers are pretty lenient on their potential contractors, because they know you probably don't have a ton of experience (if any), and most questions will revolve around your ability to spot defects. They may also give you a video to watch with recordings of bugs, that you will have to call out. Just make sure to sit up, dress nicely (you don't have to get all decked out with a suit and tie, but don't shuffle in to an interview looking like a frat bro), answer every question honestly, and to the best of your ability, and ask questions back. Try to have a positive attitude, and never ever bad mouth a former employer.


Now if they do offer you a contract... READ THAT CONTRACT!! Make sure you totally understand it. If a recruiter says that there "may" be an opportunity for a full time position "down the road", don't take that as a guarantee. The recruiter never said that there "will" be a full time position. Remember that full time openings are very rare, and when they do open, you aren't the only one looking to fill it. Also you will sign an NDA. DO NOT BREAK YOUR NDA! If there is anything you take away from this piece, it is that. An NDA stands for a non-disclosure agreement. It is basically you swearing on whatever deity you do or don't believe in, that you will not leak ANY information outside of the studio walls. I shouldn't have to say this, but that includes posting screenshots online, talking to friends about anything pertaining to the IP (intellectual property) of the project. Don't even tell your spouse about this stuff. Just don't. If you do, not only will you lose your job, you risk legal fees depending on how severe your leak is, or outright blacklisting from the industry. This is an un-official, and mostly illegal practice, but it can and does happen sometimes, since there is virtually no way to prove it has happened. The film industry has the exact same kind of un-official policies.

Ok, so now you are working on a testing team (most likely at a publisher, if this is your first gig), and you just started your first day. Well, you're likely going to go through about a week or two of training. Learning bug writing terminology, QA processes, company policies, etc. Pay attention to all of this, it is integral to your job. If you don't understand something, ask your supervisor. Every studio has their own take on QA processes, but many of those processes cross over between studios.


In your first few weeks on the floor, just get used to the title(s) you are working on. Learn the ins and outs of your title. Learn the naming conventions of all of the assets in the title. All of this info will serve you well in the near future. Whatever you do, don't blow your big opportunity by texting all day, taking/making calls, checking personal e-mail, etc. Focus on the job. This is your future at stake. Studios aren't shy about letting unproductive workers go, so keep that in mind. I've seen dozens of testers let go right off the bat for doing really thoughtless things in their first few weeks. Don't be that guy or girl.

Your first tasks will likely be running test plans. You'll get a checklist of things to test, you do those things, check them off, and turn in your report. Shortly after that you're probably going to be assigned bug reports to regress. What this involves is reading previously filed reports, and checking against the current code/build of the title to verify these issues no longer occur. Most testers find their first bug within the first few days of testing, but don't trip if you aren't finding anything right away; remember that earlier comment about patience?


The very first thing you want to do when you find a bug is to verbally let your immediate supervisor know, and log it if it doesn't require much research. Sometimes leads prefer to have everything logged right away, but others may prefer to only log issues that have been researched and verified first. Regardless every bug report is going to require you to list the steps that led up to it, and how frequently it occurs.

Once you get used to your responsibilities, take some initiative and take on tasks, volunteer to help out, offer to write new test cases, or ask for further training to help out in an advanced capacity. Again this isn't always a possibility, but it never hurts to check. Also don't be afraid to ask your supervisor how you're doing, but give it a few months. Most studios have various disciplines of QA, from basic ad-hoc testers to Compliance QA, whose job is to make sure all technical requirements are met for the consoles the title is being developed for. If your studio has these, you may want to inquire about joining one of these teams.


Now here comes the fun part... crunch time. This is where the studios separate the men/women from the boys/girls. In game development it is inevitable that you will see crunch time. And it may be nothing... like a few hours a day each week, or it may be insane (16+ hour days for weeks at a time). That usually depends on how well your project was managed in regards to development time. A good studio can get a reasonable amount of crunch time in because they prepared for it. But there will be times, even when prepared for, that you're just going to have to put in those crazy hours. If you have any after hours activities, or secondary things (band/DJ/artist/etc. careers) it's good to let your supervisor know about them first thing, so if they do end up causing you to miss OT, your manager was at least prepared for it. You may be an employee, but most managers realize some of us have other pursuits that are just as important to us. If these activities will adversely effect your career, it might be time to decide which is a higher priority, and more important to you. And it's perfectly ok to decide to have a career as an artist with a regular 9-5 day job.

During actual crunch time it's good to be prepared. This means trying to always stay positive, don't take it personally, and remember the whole team is there with you. You're a team, and each of you is as important as any other member of the team, from management on down to QA. Usually most studios try to offer incentives to keep you after hours for OT. This can be anything from catered dinners, pizzas, beer (though this is very rare in publisher QA), to extra breaks. Crunch time can also be surprisingly relaxing when most of the managers go home. Everyone tends to let their guard down a little.


Some more things to keep in mind during a crunch; whatever you do, don't lose your cool. Don't get temperamental with your co-workers, and don't start complaining about things to your peers. No one wants to be reminded of the crappy things they are trying to deal with. Most of them are keeping their minds on the task so that the stress and frustration doesn't overwhelm them. If you can't handle the stress, just tell your boss you need to go home. A manager would rather have one less body than one body that is causing issues, or dragging the team down. Also, over time isn't mandatory, but doing it, doing it well, and keeping the team's morale up is a very good way to make a great impression with a studio.

At a publisher your contract is likely to take place during the Alpha, Beta, and Release Submission phases of your title. In Developer QA, you'll also likely have a chance to work on Pre-Alpha phases. What these terms refer to is the progress of a title. It's been a while since I had to explain these to anyone, so I'll try my best now. Pre-Alpha is before any really completed levels are implemented in the code. There will also likely be mostly placeholder assets, and your testing will focus more around basic functionality of the game engine and mechanics. It's likely the script hasn't even been written yet at this point, and your team is probably still working out designs for assets and level ideas. Alpha phase is where most of the levels and assets are in game, but the actual transitioning may not be hooked up yet, the cut-scenes, are probably not even made yet. The ending is almost definitely not in yet. This is where the first wave of really hardcore gameplay testing will take place. This is where you should be finding your most glaringly obvious issues. Beta phase is basically "code lockdown/freeze". The entire game should be implemented. All assets should be hooked up, all levels transition. The ending cut-scene works, and will return the user to the title screen after it triggers. Credits are usually not implemented till the end of Beta. Multiplayer aspects should also all be fully testable and functioning at this point. Basically your code should be the final game, but with bugs still left to hunt down. Finally the Release Candidate is what you are sending to the console publisher to submit as your final build. This process can be long and grueling, especially if the submission testers on the consoles side run across any showstopping issues. Each time this happens it can set the game back by weeks. This is often the cause of a lot of game delays.


Each of these phases typically comes with a period of crunch time just before the transition from one phase to the next. These crunches can last anywhere from a few weeks to a month or two. Each project and studio varies wildly, so this is a really rough estimation. I've been on projects that dragged on for months, and I've had some that got approved on our first submission. So it's a crap shoot really. Just bust your ass, and make your game shine. Then cross your fingers.

EDIT: I was reminded in the comments, that it is also incredibly important to be prepared for the end of your contract. Make sure you know the exact date that your contract ends, so you can prepare accordingly. You should try to call your local unemployment department about a week before your contract is up. They may or may not start processing your unemployment request until your contract is actually up. But it doesn't hurt to check in with them. Alternatively, if you want to get right back into the game, start sending your newly created resume (because at this point, you should have a resume) out to studios, and other tech contracting agencies. This may sound pretty unglamorous, but it's just how this position rolls. If you repeat this process a few times, you'll have a pretty hefty resume to spread around the industry, and you'll have a much more likely chance of landing a better position. Of course like everything in life, there's no guarantees.


This post was originally going to be some thoughts on the original article that was posted by Nathan, but I guess it evolved into a QA Contractor Survival Guide, with a few thoughts on the article at the end. Here's where I'll share those thoughts.

In the original article it is implied that the studio was dishonest or not entirely forthright with the author. I can completely see where this was coming from, as it can be misleading going into an interview all starry-eyed and full of hope, to hear words like that. But as I mentioned above, no one made any guarantees that this contract would be anything more than a contract. The recruiter probably mentioned that, because it HAS HAPPENED in the past to someone at some point on the team. It's possible they do hire out of QA all the time, but that doesn't guarantee that position will even be open at any point in your contract.


The author also expressed frustration over not being recognized for his work, but he was recognized. His ideas were implemented. He can tell all his friends (after the game is out) that he contributed those map names. It's a great feeling knowing your ideas are taken to heart and utilized. But let's be realistic: no one is going to throw you a parade, or make a company announcement about it. He was lucky that someone bought him a beer for it. I've got hours and hours of awesome stories from my time in the trenches. I was personally presented a signed (by the entire dev team) special edition copy of a title I worked on by the lead designer (this designer created one of the most iconic mascots of the 16-bit era, so this was a huge deal to me). This was in recognition for my work on the title (which I won't go into any further here, because this piece isn't about me, or my accomplishments). The point of bringing that up was to show that sometimes testers do get recognition. But even if you don't, it's a great feeling to know you had a hand in creating something you love. I personally take that unopened game to every studio I work at, and just stare at it when I need a little morale boost. It's on my desk right now.

Finally, the author seemed to be under the impression that it is common for testers to move into a full time position just by kicking ass on their first contract, but in reality this is a very rare case. Full time positions usually require at least 3 years of contract experience, sometimes more, sometimes less. Particularly rock star testers can get themselves promoted through various means, but it's not something to expect going into your first studio. Don't let this discourage you. I have literally had three separate cases in my career where I ended a contract, was totally jaded, and swore an oath never to go back to QA. But it wasn't the necessity that brought me back it was the realization that I am really, really good at what I do, and I'm a valuable asset in any team. It's super important not to give up on yourself, or let the industry burn you out. It happens, and sometimes certain people will find a much happier life doing something else. This is your choice.


Some of the best things about contracts are the networking opportunities, or even just the friendships you will make with your team. I have former testers that I haven't worked with in years who I still hang out with sometimes, and consider friends. Also remember that these people you work with have memories, and they will likely leave the studio at some point and move onto another. This is a key factor in keeping your feet in the industry. I can personally attest that the vast majority of my contracts and even FTE roles have been because I had a good reference inside the studio I was applying for.

Now there are definitely some problems with the way QA are treated in many studios, but it's a problem that extends to all kinds of departments, and their interaction with each other. You just won't notice it outside of your department. It seems that there is some fundamental misunderstandings about studio departments from people outside of said departments. Often times QA is looked down upon as lazy, or a "required burden". Something that has to be "dealt with". But in reality QA is an integral part of development, and should be utilized to its fullest potential. Really good studios realize this, and go to QA for feedback, or general reports on the state of the game, control tweaks, fine-tuning, etc. Others just have their team go through the motions, and potentially release a product that is out of touch with its audience. Because at the end of the day QA Testers are gamers at heart. And who better to ask for free advice on your game than gamers? QA departments are often viewed as dens of teenagers fresh out of High School, even if half that department has kids, and mortgages to pay. This is really my only gripe with the way QA is treated in the console development world. Instead of a corporate ladder where you grab onto the QA rung first, next hit the Janitors, then the Mail Room, that ladder should be rotated on its axis so that every department is side by side, and there is no more or less important department on the team (btw - I totally just stole that analogy from my awesome boss. He's either gonna fire me, or be stoked that his analogy was reposted to the public... probably the latter). I'm just thankful everyday that I made my way into a full time position at a wonderful studio that encourages and fosters growth into the roles that we feel we are the most suited for. It took a long time, but it was worth the perseverance and patience.


You know, you've got to love your job when you spend four hours of your free time at home writing a guide to it... unpaid. It's very likely I omitted some pretty important facts and tips, so if you have any experience in the QA contracting world, please feel free to add yours in the comments.

Anonymous Senior (citizen) QA Guy

Share This Story