A new post in DICE's continuing "Inside DICE” series where developers, programmers and QA people go in depth to explain things like why there is a certain weapon in a game, or what it is exactly that they do at DICE. The last two entries were exactly that. One was explaining the whys and whats of the USAS-12, and the other was about why they changed the flag emplacement on Wake Island. In this set QA Tester Zeke Lugmair goes in depth abput what exactly he does and how he got his job.
The post is informative on what his job as a QA tester is, but the thing I got the most from this is that there is as much luck involved in landing a job like this as there is having the right amount of skill and experience.
Here is the post from the Battlefield Blog:
“As a kid of roughly eight years old, one of the most mind-blowing realizations I had was that you can actually make games for a living. Since that day, more or less all of my planning for the future was with game development in mind.
My experience as a Quality Assurance Tester (or just “QA Tester” or “QA” for short) here at DICE has really given me an understanding of what working in the games industry is really like. I got this job by a combination of luck and dedication, I guess. It all started with my high school through which I managed to get a three week internship at DICE where I got to do very basic QA stuff on Battlefield 1943.
During this time I got to know a couple of people, luckily also the man who is my boss today. Some time passed without any real connection to DICE, but after a while I started to contact them quite fiercely. I signed up for every focus test, I signed up for every video shoot and more or less did everything in my power to spend as much time as possible in the DICE office. After a while I also yet again on sheer luck started to run in to my current boss out in my free time and started to really bug him about giving me any job within my field of knowledge when I graduated.
In the end it turned that all those hours of free work and time spent yelling “I don’t care what it is, I can clean the office or whatever!” had paid off. About three months after my graduation I received a phone call telling me I had a job. And thus my time as a QA Tester had started, starting as a tester on Battlefield: Bad Company 2 Vietnam.
A Hunter of Bugs
As a Quality Assurance Tester, my goal is basically to together with our team of testers make sure the game provides proper quality compared to our plans. This mostly comes down to hunting down and reporting bugs to the right people in order to keep the game functional. However, it also includes having a good view of our project plan and being able to provide feedback to the development team both when asked for specifics and on a whim. How does a recently added feature play? Or what’s simply my general experience playing the game as a whole? As such, QA are without a doubt the ones who spend the most time in our games pre-launch”.
The general flow of functional QA work is based around finding flaws and then reporting them to the right people so they can fix it. When I just had been hired, I thought that being a QA
Tester would be considered the very bottom of the game dev food chain. Spending time here at DICE, I have however realized that QA truly is a vital part of the development process, even though there is no actual development going on.
The most general (and still very common) misconception is that testing a game is the same as playing it. Surely some of our work resembles actual play, but in order to be an effective tester one has to obtain a certain view and mindset and get an understanding of how the game actually is built.
When I launch a build (basically a version of the game) that I need to test I have a general idea of what may be broken. I would know this considering which state the project is currently in and what has been fixed or added since my last go at it. Early on in a project it might be a challenge to even be able to play the game for one minute without the game crashing or freezing. In this case it is our duty to gather all the data needed so that the programmers may analyze it, find the source of the problem, and fix it.
I think working with QA in general is a great way to get a better understanding for how games are built. Having constant interaction with all the different disciplines that make up a development team, as well as having access to the development tools means you learn new things almost on a daily basis. Over time, this helps you grow as a tester and can prepare you for other areas of game development.
A Juggler of Tasks
There are always a whole lot of different things to keep track of during one day, as we currently have three different main platforms (PC, Xbox 360, and PlayStation 3) as well as multiple project branches to attend. An essential ability within QA is to be able to juggle several tasks. I need to organize and communicate properly within the team, as it can be quite challenging making sure that all the correct info gets sent to the right people. All the while, I need to test all the different fixes as soon as possible, and I also schedule and gather the people needed for those urgent play tests. Getting organized is a valuable skill I have developed entirely here on the job, and I am sure it will come in handy in any future employment.
A regular day for me could have one of the designers coming to QA saying ”Hey, I would like to try this new spawn layout for TDM on Kharg Island, could we try this out today?” (Diego asked this???), in which case it would be up to me to find a suitable build of the game containing the new layout, give it a test run to make sure it’s not broken in any way, and then send out an invite to the dev team and make sure that we get a full server so that we can test the new layout properly.
Another recent example would be the audio team trying out some potential tweaks in the way audio is streamed in the game. The way all the different sounds in the game stack are prioritized to create the right feel, and they wanted to try out some new ideas. In this case we organized a play testing session on Caspian Border where all fighting was to take place in one particular area (we picked the Checkpoint base for this purpose). With the server full and the team running around playing as if an actual match was going, this allowed for the audio team to check whether all their tweaks were properly in place or if they had to tweak it further. During development of a game, we run several hundred play tests.
A Slayer of Accidental Monsters
When testing early content hilarious stuff will occur. If you were in the Battlefield 3™ beta you might remember the “long-necks” — disturbing looking characters indeed. They were nothing compared to the first time I encountered something similar in Battlefield 3.
It all happened pretty quickly. I was running fearlessly across the streets of Seine Crossing, turned around and saw a creature looking much like a praying mantis: About twice my size with a freakishly long neck, crooked back and distorted arms, and it came charging at me holding a knife! I was quite startled and quickly ended its miserable life with a panicky SV-98 bullet to the neck and saw it fall. Let’s just say that when we found out what triggered soldiers to take that shape, we had some good fun with that during the next play test before the fix for it had been checked in. 😉
My personal goal at work is that our games should be as enjoyable as possible with as few hiccups as possible. It’s probably impossible to ship a game with zero bugs, but I still silently curse myself when I hear about things that have slipped by during testing — even if it’s a real long-shot bug. I want to help bring our games to a state of near perfection in terms of functionality.
A lot of people ask me how to get into the industry. On a QA level it is sort of hard to give any straight-up tips in how to get here. Unlike programming, modeling or design, I don’t think there is a general line of education for the work. I do however think that the best way to go about it is to go for education that is generally required for the line of work you think you’d like to do after a few years in the business.
I know that one of my current colleagues simply saw that we were looking for new QA on Twitter and applied and got the job! I think the best way to go about is simply to push good and push hard when opportunities arise and show the company you want to work for that you are the one they would want, not necessarily by past QA knowledge but by a general interest for game development and an urge to learn. Again, there are few things other than QA that actually teaches you how to do QA. At any rate, it is a great way to take a first step into the industry.
I must however admit that my work has ruined my personal enjoyment of playing games just a bit. I now find myself challenging a lot of the games I play on my spare time. I want to see if I can see if I can break them or trigger some funky issues.”