So let’s talk about what doing the job itself is like. Let’s pretend I’m a tester and I’m working on Rayman Origins for 360 and in the very first stage I come across a checkpoint that isn’t functioning properly, as in when I die I will not respawn at that checkpoint. First of all I need to make sure it happens again and most importantly how to make it happen again. So I’ll spend some time playing with the checkpoint figuring out what causes it, once I have a basic idea of how the bug works it’s always wise to ask your fellow teammates if they’ve experienced your bug, if they don’t know anything it is always recommended to check our bug database to make sure somebody else didn’t write it up so you don’t waste any time analyzing the issue any further. However, if you have something new to add to the bug such as information or alternate steps or maybe the bug happens with more than just the specified checkpoint then you can add that information to the existing bug.
For the sake of the example let’s say this checkpoint bug is new and nobody else has found it yet. If it were me I’d perform numerous tests, often off the top of my head to try and figure out the cause. Is it when you pass the checkpoint using a specific character? Is it when carrying a certain number of collectibles? Does it happen when punching or kicking your way through the checkpoint very quickly? Does it happen after idling for a while and THEN passing the checkpoint? Does it also happen on other consoles or just on the one you’re testing? The list goes on but if you’re crafty about it you’ll eventually figure it out. So for the sake of the example let’s pretend that this bug only occurs on the 360 version at the first checkpoint in the level and when using Rayman as a character. We’ve already tested the bug with other characters and other levels and we’ve determined this is the only place where it occurs, so now that we know what causes it and we know nobody has written up yet it’s time for us to write up a bug into our database. Most bug databases will have a template we can use where we just fill in the blanks and select the appropriate variables from the drop downs, it’s always important to specify where it was found, what was found, what console it was found on, if any, etc. This is what it may look like:
Title: Xbox 360: World: Jibberish Jungle: Stage 1: It’s a Jungle Out There – First checkpoint in the level does not function when playing as Rayman.
- Steps to reproduce:
- 1) Load the 1st stage It’s a Jungle Out There of the Jibberish Jungle, make sure Rayman is the character you are using.
- 2) Proceed through the level until you reach the first checkpoint.
- 3) Activate the first checkpoint by passing through it and then die by any means.
- Result: After activating the checkpoint as Rayman and then dying, the user will respawn at the beginning of the level and not the checkpoint.
- Notes: This issue only occurs when Rayman is the selected character. This issue only occurs on the 360 version.
There are fields missing here, the most important being the bug severity. Bug severity is important because there are certain types of bugs that we simply cannot allow the game to ship with. The most severe of these categories is a class “A” bug which usually stands for crashing, hard freezing, a severe loss of functionality or broken achievements, etc. The least severe is the common “C” bug which are more minor issues such as graphical errors or minor sound errors, the issue described above I would classify as a “B” bug because while not game breaking, a non functioning checkpoint can be a severe annoyance to the player.
The variations in bugs are limitless but this is the most basic example I could think of, when we push these bugs to the developers they may send us the bug back asking for more information which is why it’s a good to idea to also include screenshots or a video of your bug in action.
It sounds pretty monotonous and it mostly is, after a while you stop feeling like you’re “playing games for a living” and if begins to feel more like work. Testers are often given an assignment, either for that day or for the week. Some assignments vary from testing the menus to only testing a certain set of levels or only using certain characters. Other times a tester who is particularly good at the game may be assigned to beat the game as quickly as possible. When we receive a new build we always need to make sure the game can be finished both regularly and with 100% completion. I worked on a game called Wolfenstein for the PS3/360/PC and one of my duties was to complete the game on the hardest difficulty as quickly as possible so I would sit there and power my way through the game every time we got a new build just to make sure the devs didn’t break the game with their most recent fixes.
Another important thing to touch on here is when we submit our game for certification. Sony, MS, and Nintendo have their own set of rules and standards games need to meet before they agree to let us put the game on their console so if they find anything that doesn’t meet their standards they’ll kick the game back to us and we do another round of testing after the issue is supposedly fixed.
There is one more important step in the QA process and it’s a word we all dread to hear: Regressions.
Since the games we test are in alpha/beta we’re constantly being given new builds (ver. 1, ver. 2, ver. 2.5, etc.) to test. These builds may or may not have fixes for the bugs previously written up so very often we’ll be assigned a pile of previously written bugs to revisit in newer builds to check and see if they are either still Open or have since been fixed and can now be marked as Closed. Sometimes a previously closed bug will suddenly re-emerge and you’ll end up re-opening the bug. This process is usually called Regressions and though a lot of us hate doing it can be satisfying to see a big pile of bugs fixed in the game, it’s also frustrating when bugs you wrote months ago are still in the most recent version.
Anyway, I’ve already said so much and I’m sure I’ve forgotten a bunch of stuff so I’ll end this post with one more thing, and that is my favorite part of being a tester: The people.
I’ve never felt more at-home while at work. Testers are usually a bunch of guys and girls who play and love games just like the rest of us, the ages vary but most of the time you’ll be in a room with a bunch of twenty somethings and thirty somethings and the discussions and the banter that goes on between testers is oftentimes hilarious and or informative. I’ve made so many friends working this job because we all have so much in common, if it weren’t for the people I wouldn’t have been able to put up with the job.
Many developers are often a pleasure to work with as well. Most notably to me were the guys at Firaxis and Insomniac Games. They have such a great sense of humor and it was an absolute joy to work with them.