Video games and homeschooling: An interview with a professional video game tester

“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.

Re-thinking vocational education

Last May, education historian Diane Ravitch wrote a guest blog post forThe Washington Post questioning the wisdom of policies that aim to send all high school graduates to college. She called this idea a sham, pointing out that only a quarter of jobs in growth industries require a college degree, and rightly noting that college will change if it becomes compulsory: “It becomes like high school or even junior high school if unwilling and unready students are pushed into [it].”

Agreed. But she should have gone further.

Unfortunately, like so many articles on this subject, her post still assumes that there is a bright dividing line between intellectual and vocational work. The first is comprised of lofty scholarly pursuits (“ancient Greek or philosophy or archaeology or sociology”); the second, trades like plumbing or building a house. She calls these latter jobs “honorable,” which is usually code for “simple.”

We see this kind of either/or thinking all the time. Smart people work with their minds. Slow folks work with their hands. If you don’t like school, you must be in the second group. But that’s okay!you’re told. That work is “honorable.”

But is that division really accurate or useful? In her ethnographic study of surgeons, anthropologist Joan Cassell stressed the way surgeons admired (and envied) each other’s knowledge and experience and other personal qualities, but especially their technical proficiency:

“Fundamental to a good surgeon is technical proficiency, or “good hands.” Lacking technical skill, a surgeon may be a good doctor, but never a good surgeon. A house officer told me that a senior surgeon, whose personal and professional behavior he described as “sleazy,” had very good hands. “He’s an elegant surgeon,” he said. When one observes a surgeon with “good hands” operate, everything looks easy, almost inevitable; the performance has a kind of rhythm, speed, and flow. Even emergencies, such as an unexpected hemorrhage, appear to be under control. Surgeons describe such colleagues admiringly, as a “superb technician,” a “brilliant technical surgeon,” a “good operator.” Of a man characterized as “the absolute essence of the ideal general surgeon,” a young surgeon said: “He just had the most incredibly gifted hands. You could compare him to Michaelangelo. That’s how much of a pleasure it was to operate with him and watch him.””

The young surgeon might also have mentioned Leonardo da Vinci, best known as an artist but also a brilliant cartographer, scientist, musician, and engineer who designed a prototype for the helicopter 400 years before humans achieved flight. Leonardo was so gifted in so many subjects that he has been described as the archetypical Renaissance man, but if he were alive today he’d probably be known as that guy who doodles in notebooks and tinkers in his garage.

If we can challenge the idea that intellectual work contains no hands-on component, it’s even easier to challenge the idea that hands-on work requires no intellect. Author and motorcycle mechanic, Matthew Crawford, Ph.D., wrote a beautiful article about this for The New York Times,“The Case for Working With Your Hands.”

“When we praise people who do work that is straightforwardly useful,” he says, “the praise often betrays an assumption that they had no other options. We idealize them as the salt of the earth and emphasize the sacrifice for others their work may entail.” This portrayal obscures the mental challenge of such work:

“In fixing motorcycles you come up with several imagined trains of cause and effect for manifest symptoms, and you judge their likelihood before tearing anything down. This imagining relies on a mental library that you develop. An internal combustion engine can work in any number of ways, and different manufacturers have tried different approaches. Each has its own proclivities for failure. You also develop a library of sounds and smells and feels. For example, the backfire of a too-lean fuel mixture is subtly different from an ignition backfire…

There is always a risk of introducing new complications when working on old motorcycles, and this enters the diagnostic logic. Measured in likelihood of screw-ups, the cost is not identical for all avenues of inquiry when deciding which hypothesis to pursue. Imagine you’re trying to figure out why a bike won’t start. The fasteners holding the engine covers on 1970s-era Hondas are Phillips head, and they are almost always rounded out and corroded. Do you really want to check the condition of the starter clutch if each of eight screws will need to be drilled out and extracted, risking damage to the engine case? Such impediments have to be taken into account. The attractiveness of any hypothesis is determined in part by physical circumstances that have no logical connection to the diagnostic problem at hand. The mechanic’s proper response to the situation cannot be anticipated by a set of rules or algorithms. There probably aren’t many jobs that can be reduced to rule-following and still be done well.”

Does it really make sense to describe the surgeons’ work as exclusively intellectual, and the mechanic’s work as exclusively “hands-on”? Their jobs are different, but both involve logic, diagnostics, judgment, technical competence (“good hands”), intense scrutiny to detail, participation in a community of learners, and years of acquired background knowledge.

Mythbusters’ Adam Savage is also a hands-on guy — and the work he does is probably even “honorable” in the sense that he inspires others with it — but no one would call that work simple. If you’ve ever watched an episode of Mythbusters, you know that all the what-if? science questions are followed by building and testing. Yet even to say “followed by” implies that the skills are discrete; they are not. Science, design, and construction are interwoven. Would you send a kid who liked that stuff to art school, engineering school, tell them to get a liberal arts degree in math or physics, or steer them towards shop and vo-tech? In an ideal world they wouldn’t have to choose, since each part feeds off the others.

In this video Savage talks about the challenges and joys of being a “maker”:

(For examples of what he means, see 10 Insanely Cool Things We Saw at Maker Faire.)

This debate is an old one. In the 1920s and 1930s, progressive education reformers like John Dewey advocated vocational work as part of the ordinary school day, and designed schools that included farm work and apprenticeships in the trades — for all kids, not just the “not-schoolish” ones. This educational model was popular with farmers in the Midwest, but immigrants to urban areas protested that they had not risked life and limb to come to America in order for their children to feed goats or work in a bakery. They wanted their children to be reading books. Both sides of this argument have merit, and it was never really settled. But that was at a time when technology did not permeate nearly every occupation the way it does today: “thinking” work required little technical competence, and “hands-on” work required little creativity.

Today, students who cast their lot with either side of this false divide — whether from fear, or from prejudice — risk falling behind in both.