If you want to get into the game industry, don't get a job in QA

Every so often, I hear about people who want to get into game development by getting a job "on the ground floor" doing QA/testing. It certainly sounds like the right thing to do, right? Start at the "bottom" and work your way up. But the game industry has a really problematic relationship with QA, and if you want to get a job in the industry as a developer, it's honestly a terrible way to do it. If you start as a tester, and you have no other "useful" skills - ie: you're not a programmer or artist - there are two likely things that will happen:

  1. You learn to be an excellent QA person, and you become invaluable in that role. Great QA people are actually very difficult to find, and a company that actually understands their value will want to hang on to them in that position. So now you're "stuck" doing QA. If you enjoy QA as an "end", and not a "means to an end", great! Hopefully you found a job somewhere that values long-term development of quality QA folks. But you also got that job as a super entry-level position, and the vast, vast, vast majority of game developers treat QA as a "disposable" resource. So rather than promote you up, you're way more likely to get laid off. And the downside of that is that the next job you get will also most likely be a QA job because that's the valuable skill you developed.

    The other issue is that if you're a programmer or an artist but you start in QA, you have almost no opportunity AT ALL to show your skills. In some companies, you may be able to talk with the developers, show your portfolio, provide meaningful feedback on the game, etc. - but it's very rare, and in the vast majority of cases, QA only interacts with other QA. So you're now mostly communicating with your "competition" for the non-QA jobs.

  2. If you're NOT a programmer or artist then there are only two potential jobs for you. Producer and Designer. HOLY COW THOSE BOTH SOUND LIKE DREAM JOBS!! but WAIT. Because everyone and their grandmother wants to be a designer, and the most likely way that a development studio is going to find a new designer is by finding someone who is ALREADY doing design-related work. A studio is MUCH more likely to hire a designer who's a community modder, or someone who's created a card/board game in their spare time as a programmer/artist, or something similar. A company is VERY UNLIKELY to magically pick a QA person out of their staff & promote them to designer. It happens, but the odds of that happening depend on how much exposure you can get to the dev team, the quality of your input, the quality of your QA work (which also means they'll want to keep you in QA if you're good, and you don't get an opportunity anyway if your QA work is bad). You have a BETTER chance of getting hired as a designer in most places if you quit your QA job & apply externally.

    So the other option is "Producer". And new Producer jobs open up fairly rarely. So if you're on a small team, forget it. They need a Producer with experience, so they'll hire an experienced person from outside. If you're on a mid-size team, MAYBE you've got a chance. If you're on a large team, your QA pool is proportionally MUCH larger, so your odds of landing that job are astronomically small.

    I know it happens. But it is in no way a "natural" progression to go from QA to development in ANY field.

I hate to say this because I've had the pleasure of working with some great QA people, a handful of whom have had genuine potential to become game designers. But we had the "small company" problem, which was that we had so few designers, and when we needed a third, we couldn't use a new person who we needed to train up, we needed someone who could operate at max capacity instantly.

As much as I tried to cultivate the people who had potential & give them opportunities to learn, the simple fact is that it's always a juggling act, where you're trying to balance the work they have to do that is invaluable to the team, and the work that they can stretch, which often is less valuable because you have to give them less-risky (proportionally less valuable) work to start. So even in an environment where I was consciously making a big effort to create opportunities, those opportunities were very, very difficult to come by.

In most companies, people aren't working to develop those opportunities, they're rarer, more limited, and often there is literally no pathway or chance to move from QA to development. So IF you're looking at QA jobs as an inroads to development, ask your potential employer not whether these moves happen, but how frequently, and when was the last time someone moved from QA into development. If they can't name someone in the last six months, then your chances of making that leap at that company are just about zero. And as a kicker, having a QA position on your resume when applying for a game design job has almost zero (and sometimes less than zero) value.

If you enjoy QA, if you love QA, then by all means, jump in. Expect to do it for a long time and be relatively unappreciated even in the best of circumstances, but if you love the job, do it. If you're using QA as a means to an end, seriously reconsider what you're doing. There are better approaches.

The flip side of this is that I wish game studios didn't treat QA as an "entry level" only job across the board. Serious QA requires experience, skill, creative thinking, and a detailed, rigorous approach to problem solving that is actually difficult to learn. A great QA person can make a really tremendous difference to your team. But as long as most teams treat QA as a disposable, entry-level, minimum-wage job, you'll get lousy results. When I worked on The Sims, we had an amazing QA staff that knew the game inside and out. The bugs we got from them saved us tremendous development time, and the rapport between developers and the QA folks was great. Then the Sims moved from Walnut Creek to EA Redwood Shores. The entire QA team got laid off, and a bunch of n00bs got hired just before release. The impact on the game was tremendous. Bugs were impossible to understand or read, and turnaround time for debugging doubled, tripled, or increased tenfold because engineers couldn't understand the bugs they were getting, reproduction steps didn't work, and half the bugs weren't even bugs, they were the game as designed. A bad QA team impacts everyone, and I think there's tremendous cost savings to be had for any team that treats QA like a serious, honorable, valuable job that is worthy of respect. Which also means that it's not a means to an end. It's a valuable end in itself.