“Testing is a job for trained monkeys”

If you want to be a programmer, you can’t really blag your way in without knowing how to program. Likewise, to be an artist you’ll need a decent portfolio and knowledge of a graphics tool like 3D Studio. Level designers usually come with a few good level designs under their belt, and most positions other than that (namely producer and designer) are filled by people who’ve worked in the industry in some other capacity. Testing is quite unique in that it doesn’t require masses of experience or any specific skill set to begin with – hence the universally low pay and status of the job – but it does expose you to a surprisingly broad array of issues in development. In the early stages of a project you might be presented with early alpha builds that demonstrate some of the core gameplay concepts, albeit without many of the fancy bells and whistles. At this stage, you’re being asked to comment on the “feel” of the game – even at this early stage it’s likely the development team will have lost a fair amount of their objectivity (they’ve probably been working on it for about a year, mind) - and part of being a good tester is having an encyclopaedic knowledge of games – cross-platform, cross-genre, cross-everything. Mindless system advocates and die-hard genre fiends do not, in my opinion, make good all-purpose testers: much better is a warm, open and altruistic love of all things “gamey”, be it Pokemon, Quake or Baldur’s Gate (hey, that rhymes). If you find yourself asking deeply philosophical questions like “What is a game, anyway?” rather than “Why do PlayStation games suck?” then you’re on the path to becoming a grade-A testing candidate...

So, in the early stages there really may be room for your suggestions and feedback. However, the project will inevitably reach a point where it gets feature-locked and most suggestions will be ignored in favour of getting things that are already supposed to be in there working properly. At this stage, you can bet that most of your time will be spent bug-hunting – either playing the game to discover new bugs (“hmmm, I wonder what happens if I try running into this door whilst firing the bazooka”) or trying to recreate old ones that may or may not have been ‘fixed’ (“hold Up when entering or leaving a room and any currently-held items will be dropped”). Ulp! At this time, it becomes handy to have a good understanding of computer hardware and the processes behind game development, as the more specific you can be about a bug, the sooner the programmer will find and fix it. If you don’t know what a sprite or texture is, or what the Z-buffer does, you might find it difficult to relate some of the weirdo things you see onscreen to the guys writing the game. Of course, that’s why a lot of testing is done with the machine hooked up through a VCR – so you can trace the often-confusing sequence of events leading to a lock-up.

So, despite the fact that no formal qualifications in testing exist, it seems pretty obvious that a deep, wide knowledge and understanding of games and the fundamentals of how they work can be a big plus. Game development is an increasingly technical business, and I would advise anyone thinking about working in it to get technical ASAP – start learning C/C++ in your spare time and find out about 3D hardware! Likewise, developing an “instinct” for bug hunting can soon become an art form – one battle-scarred tester I worked with had discovered several ways to lock up Mario 64 whilst playing it in his own time. I find that amazing: I’ve played the game for hundreds of hours and never seen anything go awry...