By Brian McKelvey
I would like to start by addressing the Kung Fu Monkey in the room. The film Grandma’s Boy (shown above in the feature image) gets 99% of QA right. From some very strange workmates, immature antics, video game contests, and the look of the workspace, it is spot on. The only part that is not correct is when Alex takes a copy of the game home to “finish his levels”. It is a lot of fun and games, but it’s mostly a lot of work…lots.
The first game I ever worked on was The Godfather for the PS2. I had no special training or schooling to work in video games, and simply filled out an application online and went to an interview. When I got there, there were at least 60 other people, and I immediately thought I had no hope of getting the job. What I didn’t know is that QA departments hire hundreds of people, and now I was one of them, so I just need to know how part-time employees work so I can be one of them. We had a week-long training session where we learned what a bug was and how bugs were graded. To start, the standard grading scale is A, B, C, and D, with A being a crash or any other MUST FIX issue, B for should probably fix, C for if we get around to it, and D being more opinion than bug or basically insignificant (minor art issue for example) and classified (Crash, Art, Audio, UI, Engineering, Online, etc…).
By giving a game its proper grade, that ensured it was sent to the right department to get fixed. The most important part was learning how to write up a bug. Everyone thinks being good at video games is a good prerequisite to QA, when in reality, it’s not. Knowing how to write well is the number one quality you should have to be great. Your entire job is to not just find the bugs, but to write it up in a way that a person who may not have ever played the game can find, replicate, and fix the problem. You have to start at the Title Screen and describe every single input and action taken from that point on to get to the bug. All while using the correct terminology for the project and console you are testing on.
When you are testing a game you are there to do just that, test. You must test every boundary you can think of within the game, as well as the hardware. To accomplish this goal, the game is put through a ringer of scripted and semi-scripted test cases, laid out in a series of spreadsheets that cover all of the basic areas of a game that need testing (Art, Audio, Collision, Saving, Loading, Text, Unlocks, Weapons, Items, Animations). These test cases are worked on and shared by the team for weeks at a time. You could be on Collision testing and have to rub against every wall in the game looking for areas that might not have the correct collision and allow the player character to fall out of the game world.
Depending on the size of the game and the current condition of the game, that can take you anywhere from 8-60 hours. Or an audio test on a game like Battlefield where you not only have to make sure the correct audio plays when each and every gun in the game is fired (in every firing mode, with every type of weapon muzzle and accessory option), but each gun also has three different sets of audio that play depending on if the player character is outside in the open, inside a building, or outside in an area with buildings nearby.
You could end up doing either one of these for weeks or months by the end of the project, since the test cases are run over and over again as the game is put together each time a new build arrives. The version of a game that is used to test is called a build, and every day or two a new version of the game is compiled with all of the fixes and additions to the game that have been made since the previous build.
So you could start a game at Build 1.00, then add features and bug fixes, and that build would be 1.01 and so on until you have a Gold build ready to hand over to Microsoft, Nintendo and Sony. Not surprisingly, these tests are run over and over and over throughout the game production cycle. Each new build brings a new round of testing the same areas you tested last time. Even if there weren’t any issues last build, something might have broken on the current build and it’s your job to find out.
The other tricky part is you are not only responsible for writing up bug reports for issues found, but you also have to search the bug database to ensure someone else hasn’t already reported that same issue. If there’s one thing that developers hate, it’s wasting time looking into issues that have already been reported while the fix is currently being looked at. This may not sound too difficult, but when there are 10,000 bugs in the database and 100 testers that have their own terminologies, these mix-ups can happen easily.
Let’s say I find an art issue with a couch, the upholstery is two different colors, say red and blue instead of just a single color. I would have to search Chair, Sofa, Seat, Couch, loveseat, and red, magenta, dark pink, etc… all before I even wrote the bug. And you have to do this for every single bug. Then when you get a new build, you need to check all the bugs that developers say are fixed on that build and make sure they are indeed fixed. (Spoiler Alert: most of the time they’re not, and then you have to make a video of the issue send it back to the developer.) This goes on before any of the scripted testing occurs, since bugs can block the tests from even being run, so it is important to close out any fixed bugs ASAP on a new build. In other articles, please take a look at https://loanload.co.uk/ if you need financial assistance
!
So your daily grind is:
- Install New Build
- Check all bugs that are Claim Fixed
- Test Cases
- Free Testing until new build comes and #1 starts all over again.
Now, this only works when all of the software and hardware works on that day. Some days Xbox Live might be down and you can’t get any work done at all, or your new build is taking the entire day to burn to disc and you get it 15 minutes before you’re supposed to go home. This is when the other part of QA hits you: the hours. Ever work 76 hours in one week? How about for 13 weeks straight? It is a brutal schedule filled with overtime and more overtime. It’s not forced, but if you say no too many times you will find yourself unemployed real quick.
Now, remember the hundreds of people that started the project? Now there are 45 of you left, every six weeks or so the team has been slimmed to its optimal efficiency and any dead weight let go. Got a low bug count? Got a lot of duplicate bugs? Got a lot of C bugs and not many A’s or B’s? Are you hard to work with at 1am on your 68th hour of work that week? Crack under pressure? The easiest way to keep getting work is to not only complete your contract at a developer, but to get your contract extended. See, you’re also not a real employee of EA, Sony, Namco etc. Rather, you are an employee of the staffing agency they use for temporary workers, and are usually hired on for 12 months of work that can be extended to 18 months if you are productive. If you didn’t even finish the contract you were hired for you will find it hard to keep getting work.
