To really do QA for a gaming company, in a way you could leverage automation effectively, the key would be process, and structuring things in a way where you ar

To really do QA for a gaming company, in a way you could leverage automation effectively, the key would be process, and structuring things in a way where you are using design patterns that let your tools cross-cut the portfolio of product. You could totally automate tests around the web service client layers of the game, but what most people think of in gaming QA is actually playing the game. That would slot in as a System test, which is your most expensive, least scalable, latest in the process form of testing, and nigh impossible to make substantive groundreshaping changes from the input of, as that experience is reliant on everything being the way it is. If you were embedded with the engine design group, you might be able to get some wins in terms of influencing architecture choices so as to make downstream automation testing more likely/doable, but from my understanding that's like being on the team that develops the crypto libraries everyone else just adopts and uses in the manner you prescribe. Plus, as a longtime QA, if game developers are as resistant to feedback as corpo ones are, and with management structures almost guaranteeing you'll be underneath the Engineering group, cutting you off at the knees the first time the words "crunch time" are implied, given the rates most get in that vertical, I'd stay away from it unless your one purpose in life is to get confronted with disappointment after disappointment as economic/fiscal concerns destroy and deface what could have been over and over again. Then again, you wouldn't be in QA if you didn't already have a tolerance to that sort of thing. Now where'd I put that bottle?