In the first of a four-part series, Shadegrown Games founder Matthew Burns remembers trying to score his first job in the game industry as a tester. Read the next part here.

Sony recently began a new reality show distributed on the PlayStation Network that follows a group of contestants as they compete, not for a million dollars or a recording contract, but for a temporary engagement at “every gamer’s dream job.” The show is called The Tester, and the response from people with any familiarity in the industry was a barely muffled laugh. Battling with others in order to get a position usually likened to grunts in the trenches or pawns on the chessboard? Striving to win the most entry-level job that game development has to offer– famous for its anonymity, low pay, and strange environs? The victor of The Tester would be in for a rude shock.

As funny as the conceit is, however, it’s true that game testing can be a good experience and an important first step on the route towards one’s game development goals. I began my own career this way, testing games for a little over two years, working in the basement of a nondescript office building in Santa Monica. I’d wanted to get into the industry since I was a child, but my naive flirtations with a career in making video games had never met with any success. So, though I was slightly dismayed with what I had heard about the game tester’s metaphorical equivalence to being a copyboy or an extra, I turned to it after it had started to become clear that my other youthful plans of attack on the great big world (such as the one where I became a dot-com millionaire, and then started a game company) had more of a component of fantasy to them than I was initially capable of admitting.

About ten years ago, then, I was placed into an interview group with five other people, one of whom had hilariously decided to wear a suit, and we were each asked some simple questions about video games that we had played, then took a written test intended to discern computer literacy but which was in practice more of a Montessori school exercise: does this picture of a cable look like it would fit into this picture of a slot? Five of us were hired (apparently the test really did confound one person) and we signed our temp labour contracts and descended into “the dungeon,” as it was sometimes called, aglow with its television and computer screens, joining the hundred and twenty-odd workers already there, ready to throw ourselves at the video games they would make us play. There were two projects being staffed that day: one based on a popular quiz show on television at the time, and the other having something to do with spaceships. I wanted very much to avoid the quiz show game, so I made certain non-subtle references to my expert knowledge of fictitious spaceships to the men in charge and soon found myself in front of a computer, sandwiched into a row of other testers too absorbed in their own interstellar battles to say more than a few words of greeting.

Most explanations of game testing as a job begin with the sober admonition that is most certainly not just “sitting around and playing games all day”; that it is, you know, an actual job and entails actual work. Of course it is, but it must said that while, yes, it has certain expectations, responsibilities and so on, entry-level game testing would not be found near the top of a list of the world’s most demanding livelihoods. Generally one spends a lot of time in front of a screen and a single game, eight or more hours a day, day after day. To the extent that there could be said to be any sort of mental exertion, it would centre on finding and writing up bugs: short descriptions of problems in the game, roughly analogous to incident reports or trouble tickets. Bugs are “opened” and get routed through an often grimly bureaucratic process until the person responsible for the relevant piece of the game receives it, fixes it (or explains why it should not be fixed), and sends the bug back to be re-evaluated and hopefully “closed”. The theory is that the number of open bugs will decline gently and inexorably towards zero as the ship date approaches.

In practice, of course, it goes a little differently: the big deadline seems far off, then suddenly it is closer than anybody realised and panic sets in– a slow, institutional sort of panic, the kind with plenty of time for rationalisation about how we are not panicking. Someone, usually a producer, abruptly becomes the voice of reality (or the dream-killer, if you prefer) and rampages through the database, closing bugs en masse, marking them “will not fix”. The numbers take a dive, as does the quality of the final product. It’s no coincidence that one of the central metaphors used in shipping games is landing a plane: the team feels its collective stomach in its throat for a moment while the project descends towards the ground at disconcerting speed. So although it is the game tester’s job to scrutinise and describe every flaw or potential flaw in the product, the department’s purpose is not to seek bug-free code in the sense of an unreachable infinity of perfection, so much as it is to help ensure that the company will not get sued by consumers when the game is released. More charitably, it is to confirm that the level of quality requisite to the product has been reached and that further effort is not necessary. An executive once compared the department’s function to that of a sphincter, holding onto things until they are ready to depart, an analogy with certain implications of which I am sure he was fully aware.

Continued in Part Two...

Matthew S. Burns is a writer and videogame designer. Prior to going independent, he was a producer at Bungie where he worked on the Halo franchise. More of his writing can be found at www.magicalwasteland.com.