“What if he just sits around playing video games all day?”
It’s one of the most frequently asked questions from parents considering homeschooling. This issue comes up almost as often as the “S-question” (“What about socialization?”), but unlike the S-question — which is usually easy to answer — the dreaded “V-question” is controversial. Some parents are very strict about screen time, and may ban video games outright. On the other end of the spectrum, there are parents who don’t believe in squashing any of their children’s interests, and if gaming is what they like to do, then by all means enjoy it round-the-clock.
But the vast majority of homeschooling parents lie somewhere in the middle: one of the reasons they homeschooled in the first place was to give their kids more freedom, but now the single-minded focus on video games seems uncomfortably obsessive. These parents get bashed from both sides: the screen time enforcers call them lax and negligent, while the follow-your-own-interests crowd decries them as fascist and controlling.
And then, inevitably, someone will wander into the conversation and point out that mastering video games is as valid as mastering any other skill, since, after all, gaming is a big business.
It’s that last claim that interests me, because while it’s true the video game industry is huge, I think it’s widely misunderstood. As luck would have it, I have a friend who’s spent more than a decade working in this industry, and he graciously agreed to be interviewed about his job. The main takeaway? Getting your foot in the door as a video game tester is easy, but that work is insecure, poorly-paid, and not very interesting. As you advance, the work pays better and is more rewarding, but to do this you will need skills beyond “plays a lot of video games.”
+ + +
Q. What’s your official job title? Tell us in technical terms and then describe it in regular human language.
A. My official job title is “senior test lead.” What this means in practice is I manage teams of about 40 people (give or take, depending on project) in testing various new features of a console and how they interact with various titles in the pool of titles available for that console. The titles themselves have already been released in most cases, or are very close to release; we’re testing whether or not any new peripherals, interfaces, etc. will break those titles in any way.
Q: When I think of someone who tests video games for a living, I imagine someone who plays games all day and then makes a phone call to their boss upstairs, saying, “Yep, this game’s fun! Release it to the world!” or “Nope, this one needs more work, send it back.” But I’m guessing that’s not actually what you do. Or is it? What DO you do?
A. This is kind of the scenario that we lure people in the door with. “Would you like to play games all day and get paid for it? Then you should come work for us.” In practice, that’s not really how it works out, naturally – at least not at this level. Testing of the type you describe *does* happen, but usually it’s called “beta testing” or “usability testing” and it’s unpaid, or paid in product only. By the time a game gets to that stage, it’s basically ready to ship.
“Functional testing” does, indeed, interact with new, unreleased titles all day. They are the last line of defense before a title is released. They get a few days to play it through, but usually they’re not “playing” in any traditional sense. Most of them are running them against test cases – such as, “what happens when you idle at this screen for 15 minutes”, “does the game provide appropriate messaging if you do [thing X]”, that sort of thing. One person does get to be “the rabbit” and their job is to race through the title as fast as possible – this is really the closest you will ever come to a person who is “getting paid to play games all day.”
My testing, which is “consumer acceptance testing,” sometimes lets you play games all day and sometimes does not. We have one test case that allows people to play multiple titles for various periods of time over the course of the day, and just record a few metrics while doing so; people like this test case. We have other test cases that, say, require you to boot the console over and over and over, all day, using various methods. People like that one significantly less.
There’s other types of testing that goes on at game labs – like “compliance” testing, where you basically boot a title over and over using various connection types, monitors, etc. and never actually see gameplay. And then there’s the testing that goes on at development studios which is a whole ‘nother ball of wax, where you’ll “play” the same title, over and over, in various iterations, for sometimes over a year. Just that one title. I hear you get really, really sick of that title by the time it ships, but that kind of testing can be a good foot in the door to higher positions in a developer studio, especially if you know programming.
Q: When our friends learned you’d gotten this kind of job, we all laughed (appreciatively!) because it seemed like such an obvious fit – we all played video games occasionally, but you played them in 30-hour marathon sessions. But I ALSO remember that you were a big history buff and did well in math and knew how to program. What sorts of skills and education do you bring to your job?
A. Perhaps surprisingly, you don’t have to know very much at all to get in at a testing position in a game testing lab. A lot of the things we do are not complicated, and mostly require a lot of bodies. The hiring process is generally “can you work [day X]? Then come on down.” At that level, you are essentially an on-call hourly worker with no job security. You get paid minimum wage, or close to it. You might work when there is work, and you won’t when there isn’t. Sometimes, it can be a long time between projects (weeks or months). This is where I started.
Some testing labs (fortunately, mine among them) will promote people from within to higher level positions within the company as they exhibit ability. Attention to detail is a big plus – your job is to find bugs and issues, and if you’re not sharp of eye you might miss them. Attendance, sadly, is also a huge plus – this will come as a surprise to you, I’m sure, but people who want to game above all else sometimes aren’t interested in showing up for possibly unpleasant work activities. You have to be able to execute boring, tedious tasks for hours on end, day after day (while still remaining conscious enough to exhibit the aforementioned attention to detail). If you show leadership skills, such as helping your fellow testers with test cases or issues, people might consider you for a lead position, where you (usually) won’t be executing test cases any more but instead managing teams of other testers to help them execute test cases.
After a few months or years, sometimes you can lever your experience game testing in game testing labs to other positions in game studios or publisher, especially if you know how to code (better than I do – you say I knew programming, but I was really, really bad at it. Our secret, shhhh). Programming is extremely helpful to rise in the gaming world as a tester – I can’t stress that enough. Without coding knowledge, all you’ll be able to do is “black box” testing (which is mostly the kind of testing I describe above in your second question) where you’ll be doing various things to the title/console, but you won’t really know how those processes are supposed to interact on the inside. If you know programming, you can do “white box” testing where you stress the code directly, and that kind of testing is paid significantly more and has much better job security. From there you can sometimes go onto actual development as well, and in game development, all sorts of eclectic skills can come into play. The game studio Valve, for example, has full-time writers, economists, and even psychologists on staff to help them add story and realism to their titles. But getting to that point requires, as a general rule, good programming knowledge.
If your programming knowledge is not great, but you have those good leadership skills, you can at least hope to be promoted to lead and maybe senior lead. From there, the things you learn are more business/administrative – managing teams, filing paperwork, hiring and firing, meetings with clients, that sort of thing – although you still have to have a good eye for issues and good judgment. But these positions are few and generally prized, and most people who get them stay there for years – unlike testers with programming skills, where new positions with better pay (certainly better than what I get paid) are opening up all the time.
Q. If you knew a 15-year-old who wanted to go into this industry, what would tell them to do now to start preparing?
A. Pursuant to my answer above: learn to code. Learn hard. You can be self-taught – that’s still a way to go; people care more about what you can do than what certifications you have. But if you’re self-taught, be prepared to discard assumptions you’ve made along the way. Notch (the Minecraft lead developer) was self-taught, and was self-admittedly not a great programmer as a result, because he learned a lot of things in a way that didn’t lead to very good code. Many programmers work as a team, and you will generally be a better coder if you learn with and from others.
If what you care about is developing titles – develop some. There are a large number of great tools and engines out there that will help you get started. Many are free, and they don’t require knowledge of coding; and better yet, using them might teach you something about scripting (which is kind of “programming lite” and super-helpful for understanding coding and coders). RPG Maker Ace, Unity, Torque, XNA – these are just a few names of many, and a lot of them have free trials or stripped-down free versions. Some games even have “build your own adventure tools” inside the game itself, like Neverwinter’s Foundry. Downloading one and playing around with it will give you a great idea of the kinds of things that go into developing a game. And if you successfully develop one, you’ll have something in your portfolio to show other people who might want to hire you.
If all you care about is getting a job that sometimes *plays games* – you don’t care about developing, you don’t feel like learning to program, you just want to work somewhere where everyone is as obsessed about games as you are – then you still need to be prepared to move to a city with test labs and developer studios, work long hours (or no hours), spend time doing mind-numbing things, and budget meager paychecks – in short, a lot of the things they “teach” you in high school. The main difference is that at a game testing lab, if you play hooky one too many times, you don’t get to go back. The job is, as one of my co-workers frequently put it, “better than digging ditches.” And sometimes, you will get to play games all day, for pay. Not too often, and definitely not as often as the recruiters will imply to you. But sometimes.
Q. I’ve heard that musicians and non-musicians listen to music differently: those who just enjoy it relate to it on a creative, emotional level, while those who play it also listen to it on a technical level. I know that when I’m spending a lot of time writing or painting, I definitely read and look at art differently, paying much more attention to craft. Do you approach video games differently now that you’re not (only) a player, but also involved in the creation of them? Are there things you notice now that you didn’t before?
A. I think I’m still more a player than really involved in the creation of the title. My ability to influence a title’s development is extremely peripheral if present at all, no matter what department I am in. I’m not involved in the design document, the roadmap, any of that sort of thing. I’m a cog in the machine, and just one of hundreds at that. So I still tend to look at games as a player in most respects.
What my time here has made me much more sympathetic to is the bugs themselves. The whole testing process is directly related to time. Finding bugs, fixing bugs, finding the bugs that got created by fixing the old bugs… that all takes time. Sometimes testers don’t find bugs because they didn’t have enough time to thoroughly test a feature, and sometimes developers don’t fix bugs because they didn’t have enough time to fix it right. Issues are judged on severity, and the most severe game-breaking issues are of course (usually) fixed, but that frequently means that other, more minor issues aren’t. So now when I see some kind of graphical occlusion or glitch, or something doesn’t make the right noise all of the time, or some process isn’t quite balanced, I don’t berate the developers, or the testing labs, or even the publishers. Sometimes, there are just bugs, and the nature of the development cycle is that sometimes games get released with bugs. You can’t fix everything.
I also read the list of credits at the end of games much more closely, because sometimes my friends are there. Testers that tested titles directly at the studios generally get listed at the end of the credits. It’s like being the 3rd assistant gaffer at some Hollywood movie. You played a small part, but you played a part, and it’s cool to see your name or the name of someone you know in the lights, even if it’s only for a second.