Yep, QA is the way to becoming either a developer (coder) or associate producer (slave for real producers). Artists, writers, other folks, you can go this route too, though I am not sure if it will help as much as a degree from an accredited school. Generally, getting a Quality Assurance job is fairly easy if you’re asking at the right time, for the right company. Smaller developers are more difficult to get into since they have fewer positions and fire people less often, less turnover. Publishers and places like Microsoft are incredibly easy to get into, however the larger the company the worse they will treat you. Developers are generally nicer to their QA staff.
I should explain that console manufacturers certify games (certification testing) before they allow them to be released. So what this means is not that the game is any fun at all – believe me, many games you will test are horrible, wretched titles that need to go back to the swamp in new jersey from which they arose – just that the game starts at the title screen when you press the start button. There are a number of other requirements for certification, these make up the Technical Certification Requirements (TCR/TRC, both are the same). Separately, the game is also certified for assurance that the game is functional, which is known as (can you guess?) functionality testing. Functionality testing often pays less, and is more demanding. Though you’re more likely to play the game with functionality testing than you are with certification testing.
So, you’ll see certification testing at console manufacturers, like Microsoft, Sony, and Nintendo. However, studios/developers that make games often also check the game before it gets to the console manufacturer. It costs developers/publishers money to send the games through certification testing at the console manufacturers, so the developer and publisher will test it beforehand.
This is all relative of course, I am treated very well at my current QA position. Mostly due to the fact that I have managed to get work with a smaller developer. Besides being the most charming Quality Assurance Engineer on the planet, there are other good skills for interviewing for this kind of position too. Ahem, ordered paragraph list, please!
- Know some games you like, beyond just “Metal Gear Solid is awesome!”. Talk about how you think that perhaps Hideo Kojima should have gone a little bit easier on the story arc and made it less confusing. Or about how Halo 2 has obvious Level of Detail errors during the cutscenes. People you talk to at your prospective employer will want to hear about your real interest in games, if they don’t hear it, they will think you’re just there because you think the job is easy (regardless of you saying exactly the opposite). You must sound interested and well-prepared.
- Along with the LoD errors in Halo 2, mention other things you’ve noticed in games that seem to be broken, like the time you fell through the world in Grand Theft Auto 3. Or how Doom 3 had a monster closet where the AI failed and the monster stood there taking fire until he died without responding. Stuff like this is real good fodder for talking during the interview.
- You may get asked ridiculous questions. How do you test a stapler? How do you test a chair? Et cetera. This is (in my opinion) totally useless for actually finding out if you can test anything. People think that questions like this mean they’re smarter for asking them because they read about it in some fancy interviewing book. These people are morons (in my opinion). This may be useful for finding out how well you deal under the pressure of being asked a bogus question while working under pressure.
- Don’t dress well unless you’re interviewing for a testing position on an IBM game. Jeans and a slightly fancy shirt are OK. A suit is too much. Obviously everything should be clean and have no visible stains/cat hair/stink like pot. Please also shower before the interview and put on deodorant.
- Know what you’re getting into. QA is not easy. The lowest paying and first jobs with QA are the ones where you only test for functional crashes, this is where you will sit in a cave with 60 other sweaty testers playing Barney’s Cookie Eating Adventure for 8 hours a day until the game won’t crash anymore after it has been rejected and sent back to testing 40 times. You may get stuck with this kind of testing no matter what you do if all the other positions are fully staffed.
- Arrive early, bring a Nintendo DS or something to play whilst you wait, especially if you get nervous around interviews. It’ll also give you something to talk about with anyone who walks by and inquires about what game you’re playing.
- It’ll help if you’ve done some work outside of testing, especially anything else game related. I write (terrible) reviews for various games on web sites, and maintain various open-source game projects. These are also good talking fodder, and especially good for filling your resume before you have a lot of testing experience.
- Take any water that is offered to you. Don’t drink red bull or something else that will make you edgy.
- Have fun with your interviewers, if you can crack some jokes, do it as long as your audience is receptive.
- You may be asked to demonstrate your testing skills in some way. I can tell you that I’ve been shown prerecorded game play of obviously unfinished games and been asked to report errors I’ve seen. Don’t worry, the errors in these are obvious. Real testing generally doesn’t have such obvious errors, especially if you are going for a publisher/TRC, TCR approval position. Developers usually iron out really big stupid errors before they get to that point unless they are under extreme pressure from their publishers to get things to certification. I’ve also been given an actual in-test game and asked to test it, this is actually easier than the video tape version in general.