Pad
Happy:
Everything You Ever Wanted to Know About
Game Testing
|
Vol.
2, Issue 7
December 23, 1999
|
“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...
