Working in QA

ImageGen

At about the age of 17 I met a girl who told me her boyfriend was a games tester; to me this seemed like the holy grail of jobs. I imagined sitting around all day with a bunch of mates and playing a couple of games, after all that is what we generally did for fun after school. However, as I made my way through College and University the idea of being a games tester slipped to the back of my mind along with all the other “that will never happen” job scenarios many teenagers have like becoming a rock star. Fast forward almost 10 years and I had just graduated from University with a degree in Multimedia Technology and Music Production; I planned to pursue a career in Audio but didn’t know where to start. Still a big gamer I decided to look at audio jobs within the games industry and so I attended a few open days and generally began seeking out more information about my chosen career path. During one open day the QA manager of the company I was visiting explained a little bit about the job and recommended QA as a foot in the door to a development role.

My first job in the games industry was indeed as a games tester or QA (Quality Assurance). I held this position for about 1 ½ years before moving into the development side of the industry as an Audio Designer. To many gamers, QA is a mythical job role where geeks gather to play games all day and hone their skills. On the flip side, many people not into gaming turn their nose up when you explain to them that you test computer games for a living.

With this article I aim to explain what QA do on a daily basis, debunk some common myths and give an insight into what it is really like to be a games tester. So, where do you start?

The interview

Generally you need to scour various games publishers and developers websites; here they advertise new job roles.  Remember QA jobs are generally temporary and companies normally only advertise a few months prior to a game hitting the shelves.  Generally no prior experience or qualifications are required, but they certainly help. When I first applied for a job in QA I sent CVs to several companies and was successful in getting an interview. I can’t say what the process is like at all games companies but for this job I was required to complete a short application form and after a couple of weeks I had an interview lined up.

The interview was presented in two parts; first of all I had to complete a short exam of sorts. The idea here was to weed out anybody who isn’t really that interested in games, after all you don’t make an ideal candidate for the job if you don’t even like games. The exam mainly consisted of pictures of old tech, games and consoles and asked the examinee to correctly identify each one, nothing too drastic! The second part was the actual interview which covered the basic questions asked at most interviews such as “why do you want this job”, “why did you leave your last job” etc… The interview then moved onto games where I was asked to list my favourite genres and games and talk a little bit about my choices. QA questions were also asked, such as “what do you think is involved in testing a game” and “how would you approach testing X part of a game…”

The risk you have to take

A few weeks later I received a phone call and was informed that my interview had been successful. Now a predicament many new starters have to resolve is where they will live, do you commute or move house?  As QA jobs are generally offered on a temporary basis your contract may not be renewed in 6 months time, whereas your tenancy might last 12 months. I absolutely didn’t hesitate over this decision and immediately found a place to rent 15 minutes away from where I would be working.  When starting out on a career path you have to take risks and think positive; the company are working on other games, if I prove I can work hard they might renew my contract.  During my time in QA I did indeed experience the dreaded QA layoff period, luckily I survived (in part because I was transitioning into a different department).

The Job

What is it actually like to work in QA?  Well the “dream job” status I once applied to games testers as a 17 year old had long since vanished before I’d even applied for the role; I was now applying as a necessity to get into the games industry. I’d hope anybody who is old enough to seriously consider becoming a tester understands that this is a real job, involving serious work, carful observation and long hours.

The day I started in QA I joined the 14 or so other new starters; we were taken to our seats in an open plan room containing around 40 other testers (one of two main QA rooms).  My first task was to open up an old build of a previously released game and identify several bugs (which had purposely been left in that build), after a day or so on this task the real work started.

The common myth seems to be that working in QA involves sitting around all day playing games and while this is in part true the bulk of the job involves a lot of paper work and organisation. Tasks are split up into looking for new issues, confirming issues and testing old issues, this is very repetitive work and this is where the realisation kicks in that this is indeed a job, not a hobby. In a typical day you could be given a list of new settings to play with, you may have to use a 19” CRT TV and play with the saturation low and the language set to German. All eventualities need to be covered and so just because the majority of gamers might now play on 42” LED HD TV’s there will be a small percentage of players who only have access to a CRT TV. Audio is also tested, be it on headphones, TV speakers, stereo speakers or a surround sound system. Audio options need to be adjusted such as playing with the speech fader set to 0% if applicable, any speech heard will then have to be entered into a database as a bug.

As well as your settings you may then be given a very specific task to complete. Here are a few examples and outcomes that could happen to give you an idea of why they need to be tested:

Task
Walk against every wall in the level

Example of a bug
The player may find walls with no collision properties. This could cause the player to fall out of the world or access areas of the game early, causing further bugs and progression issues.

Task
Complete the game without upgrading any weapons

Example of a bug
If the game is structured into levels with upgrades only taking place at specific times the player may reach a level in which they cannot kill a certain boss and cannot return to the upgrade area.  This will then halt progression indefinitely.

Task
Drive around each track the wrong way

Example of a bug
Game logic may not be able to deal with a player completing laps backwards.  Warning speech or visual notifications to inform the player that they are going the wrong way may not trigger.

Bugs are listed into a database where several important pieces of information is added, this is where the tester needs to be organised and clear about an issue.  Relevant information or sections to complete might include:

–        Type of issue (AI, Audio, graphics, logic etc…)

–        Priority (Is this a priority 1 and causing the game to crash, or a minor issue such as a characters arm clipping through a tiny piece of wall?)

–        Build number (builds are generated often, if somebody else is playing in an older build they may think the issue isn’t present)

–        Where the bug occurs (game mode, level or mission)

–        Other specifics (using the power sword, driving the Ford, when playing online etc…)

–        What platform (Xbox 360, PS3, PC etc… the bug may not occur on all platforms so they all have to be tested)

–        How often the bug occurs (e.g. 1/10 times, otherwise somebody may re-test this issue 3 or 4 times and decide it is now fixed)

–        Method of reproduction (so the developer or QA can test the issue again)

Once a bug has been completed it is then assigned to the relevant department to be resolved. After the issue has been fixed it is then returned to QA as a fixed issue, the testing doesn’t stop here however. All fixed bugs are once again tested (using the method of reproduction) to confirm if the issue is fixed. If there are still problems the bug will fail, a new comment will be added by the tester who failed the bug and it will once again return to the developers.  In some situations a bug may be returned without being fixed, this may be a “no fix” or “cannot reproduce”. A no fix can arise if a tester has incorrectly flagged something which may actually be a feature or a tech related issue which simply cannot be fixed (an example of this can be seen in large open world games such as Skyrim or Read Dead Redemption where textures may pop in and take a while to load but cannot be made to load in any quicker). “Cannot reproduce” issues can generally arise if the tester has not given enough information to reproduce the bug (e.g. the bug may only occur when using a very specific weapon which the tester didn’t mention). Alternatively QA can generally be several builds behind the development team and bugs may have already been fixed in a newer version of the game which the tester has yet to receive, nullifying the bug.

As well as seeking out new bugs other tasks may include reproducing existing bugs on all platforms. Let’s say a tester finds an issue on PS3 and enters a bug, this bug could be exclusive to this platform or may happen on all platforms. To verify this, a second tester may go through all bugs which have been found on PS3 but have not yet been checked on Xbox 360. The tester will follow the method of reproduction for each bug and confirm if it also happens on the 360.

Towards the end of a development cycle other tasks will be carried out such as completing the game from start to finish and perhaps meeting certain criteria along the way. Take inFAMOUS as an example; a player has the option to choose good and evil options throughout the game, resulting in two different experiences. This task is perhaps one of the more tedious jobs a tester has to complete; arriving at work in the morning and doing a full play through until your shift finishes may seem fine on the surface. Now remember, the tester may have been on the same game for the last 5 months, 3 of which might have included a lot of overtime. They probably know the game inside out and may not even enjoy playing it.

Taking on the role of a QA tester is full of pros and cons and when people ask me about my time spent in QA I always tell them the same thing. The job can be very tedious at times but I’d much rather be in an industry I love, getting paid to test games than standing in Sainsbury’s stacking shelves of meat for 8 hours at a time (as I did while at University). The job is also relatively low paying, I won’t mention how much I earned but a recent MCV survey lists the current average wage for QA[1]. This is coupled with the risk you take of entering into a temporary contract in an industry which is plagued with studio closures and redundancies.

Development cycles also experience “crunch” periods, typically this can last for several months and everybody from development to QA are required to work overtime to get the game finished for the street date. Often you hear stories about QA and Devs sleeping under their desks just to get a game finished. I can’t say it’s ever been that bad for me but there have been times when I’ve left the office in the early hours of the morning.

Moving onwards and upwards

QA is one of the best ways to get into the games industry and to begin understanding development cycles. Working with development builds, test kits and seeing a game progress from an almost unplayable state to a polished master all contributes to your understanding of the development process. Identifying and logging bugs also provides a great background for development as you start to learn the basics as to why bug are occurring and how they are being resolved (developers may add comments or small details about the fix to the bug report). This process is especially useful when identifying bugs related to the department you are interested in; in my case I wanted to progress onto the audio development team. I would look for any audio related bugs, which would help me understand what should and shouldn’t be included in a game. My bugs would then be fixed and sent back for me to check, generally there would also be a comment added such as “re-exported the asset at the correct sample rate” or “asset was 500kb too big, causing a crash”.

Another great benefit of being part of a QA team is the ability to interact with developers on a daily basis, not just within a working environment but socially as well. On your commute to work, around the office and in the canteen you can get to know the people you work with. Some QA are lucky enough to receive feedback on their portfolio or apply for vacancies advertised internally (many developers start off in QA). As well as the development team you are also surrounded by like-minded graduates, rarely did I talk to people in QA who did not have some sort of degree in programming, games design, art and other disciplines. This can provide a good opportunity to work alongside friends on your portfolio, learn new skills or make links with possible future developers.

The pros and cons

Pros of working in QA

–        Essentially you play games for a living

–        Work in an industry you love

–        A chance to network with developers and graduates

–        Build up background knowledge of the development cycle

–        A foot in the door to a development job

–        The ability to apply for internally advertised jobs

–        A good opportunity for feedback on your portfolio

–        Your name in a list of credits

–        A copy of the games you work on and discounts on other games

Cons of working in QA

–        Low paying

–        Normally temporary contracts

–        During overtime there are long hours and weekend work

–        Working on one game for months at a time can become tedious

–        Difficult to get a promotion

[1] http://www.mcvuk.com/news/read/uk-games-industry-salary-survey-what-are-you-worth/0110018

Advertisements

2 thoughts on “Working in QA

  1. Pingback: Working in QA – Part 2 | leavelucktogames

  2. Pingback: So you want a job in the games industry? Musings from Codemasters Birmingham audio department. | leavelucktogames

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s