A game is going to have to be in pretty good shape before it's stable enough to run for Q/A testing, i.e. it's already been through a ton of internal testing by engineers.
To a point yes, but very few games start from scratch these days so there is something playable very early, so QA is involved very early on. Often way too early IMO.
The games industry in general does not have a history of formally testing things, engineers obviously test their own code, but there is a lack of definition of correctness at a macro level.
Going off on a tangent for a minute. The WORST design documents define the behavior of a particular AI, but when implemented to the letter, often when interactions outside of the scope of that design are encountered things fail very badly. The best designers describe the intent of the design so an engineer can adjust the implementation to suit, rather than getting into a never ending cycle of chasing edge cases.
A lot of what an engineer does on a game is putz with edge cases that were not foreseen in the design, or initial implementation. Yes this happens in all large scale software to some extent, but IME it's a much bigger issue in games than in most software. It's a lot of the reason games are so difficult to estimate time on and why they slip.
There has been a push to move these types of things directly into the hands of designers, but all you are really doing there is adding a requirement of an engineering skill set onto the designer, and basically hiring some very junior engineer hopefully with some design sensibility.