@YankeeJim
Thanks for the compliments.
My QA department has been 4 people strong for as long as I've been there. I imagine WGT's QA department is probably about the same size, if not smaller. Things are harder to reproduce in this type of environment. On a website you can usually give clear and concise steps to reproduce an issue.
That's a lot harder to do in-game since there are almost an infinite amount of scenarios. Stuff aways falls through the cracks. Especially some of those deeply nested bugs (called edge/corner cases) that require 15+ steps just to reproduce.
Most all programming is modular. Which means that many people are writing and contributing code that never interacts until integration. Most developers work in their own test environments, but often are required to jump into someone else's code and figure out what's going on. Often times two or more developers will make changes to the same line in the same file, and you end up with merge conflicts that need to be fixed before you can commit all the code together.
You also make a go no-go decision the day before release. I'd say they found that they borked the camera pretty quickly (and the sounds issue too), but the the time to take to fix it probably would have postponed the release itself.
So, the next question you always ask is this: Can people still accomplish the main functions of the game/website despite the presence of these errors?
Yeah, the cameras are goofy and the sounds are messed up, but this doesn't detract from the core ability to still play the game. So, you release anyway with non-critical errors, and target a fix for those in the next release.
It's not uncommon to push with non-critical errors. At any given time they are probably 100-150 active bugs on our ecommerce site, but many of them are non-critical, and frankly not worth the $$ to pay the devs to fix it.
I had a TRS-80 too, complete with the tape drive. I still dabble in qBasic programming today. =)