Archived Rare Life Profile: Tester

by Lerako on Apr 2nd, 2012

Before I go on to tell you what it’s like to be a games tester there’s something I must warn you about. If you were hoping this little insight was going to say something like, “Testing is easy. All play and no work. Play games casually all day. Just have to be good at games etc.” then I’m afraid I’m the bearer of bad news. Read on to find out what it’s really like to be a tester.

I’ll get the most frightening fact out of the way first. The worst downside to being a tester is the fact that it takes the fun out of playing games in your spare time. You find yourself subconsciously looking for bugs in them and not playing the game how it was meant to be. Luckily this unwanted sixth sense fades with time (and for the less patient of us, hypnotherapy is always an option).

With the bad and the ugly out of the way, on to the good.

Typically, you only ever test one game at a time as it goes through its testing/debugging stage (which comes right at the end of the game’s development life), although during busy periods two or three titles may be in testing at once. Titles also need a sufficient amount of testing prior to the major shows such as E3 and the Tokyo Game Show. Show demos provoke mixed feelings as it feels great to be testing and playing a title no-one outside the company has seen yet, but due to them being very early versions, a lot of hours and work need putting in to get them into a playable demo state. There is just a single, large Testing team at Rare, responsible for testing all of the games prior to their release.

Whilst testing a game, you’re primarily there to find bugs within the latest version of whichever game is currently in testing. When the next version arrives, you re-test all the known bugs that existed in the last version along with looking for new ones. When first starting the job, bug-finding is not easy. It’s as if you’re totally blind as to what bugs can be found in a game. (On my first day I was telling the head tester how bug-free I thought the game I was playing was. In the time it took me to speak that sentence he pointed out to me that I’d just gone straight past at least two bugs I never would have noticed. Very embarrassing.)

There are loads of different bug types that can exist in a game, and there are plenty of them to find. In fact there can be up to several thousand bugs to find before a game hits its deadline including lock-ups, out of environments (where you get the character in to an out of bounds area) and loads more general weird stuff you can’t possibly imagine. However, with time and experience you get to the stage where it seems like you can’t play the game for five minutes without finding a bug to report.

All the while you test the game, you’re videotaping what you’re doing so that when you find a bug and report it, you can include the tape counter. This is for the development team’s (programmers/designers/artists/musicians) use mostly, should they need to see exactly how you got a bug to occur. You get a sick satisfaction when showing a programmer a bug, which you know will give him a headache and excuse to stay at work until two in the morning trying to fix it. This is a definite perk of the job. You also get the same level of satisfaction if you ever manage to repeat a bug that a team member swears blind (at you) they fixed. You get the feeling they want to run you through with a sharp metal object. Luckily they never have the time or energy (or the athleticism of a pot-bellied tester) to carry out such a feat.

When a game first arrives in Testing, the working hours aren’t too bad but do go up gradually over the testing period. As the game approaches its deadline with the speed of, err, a game approaching its deadline (really fast), you soon find yourself working very long hours for the last three or so weeks. This is the norm for N64 titles, though Game Boy Color titles are not quite as time-consuming due to their reduced size and complexity. Also time goes more slowly when (violins out everybody) you have to keep replaying a one-minute section of a game for eight hours trying to repeat a bug that needs repeating to help a programmer understand how to fix it. Don’t try this at home as without the correct training you will bore yourself to death. However, I’ve personally found that the more difficult a game is to test, the more rewarding it is when the game finally becomes a finished product.

A really enjoyable aspect of testing is the fact that you’re surrounded by like-minded people who all share a common interest. This makes the job a lot more enjoyable and makes testing more fun at times like when trying to set records in a game. Racing games in particular provide heated but friendly competitiveness when trying to set course records.

Throughout the time a game is in Testing you also get to make any suggestions to the team about their game, no matter how big or small. All the feedback they receive is vital, as the teams often find it hard to be objective when they’ve been working on a game for a long time, and sometimes when a game comes into Testing we get to say to them that particular areas just don’t play well and suggest how they could improve them. When a game is finally finished it’s one of the best feelings in the world. (Unfortunately this only lasts as long as it takes for some spotty school-kid to write into a magazine with their ‘top score/record’ that beats you at your own game. I hate it when that happens.)

Categories: News