View Single Post
Lt. Commander
Join Date: Dec 2007
Posts: 120
# 24
03-16-2010, 02:41 PM
Originally Posted by Reaper11188
-----QA most often, will not get the final say as to when something is released and in what state.----

That bit right there is the main flaw with most MMO developers/ the MMO world, the tail wags the dog, and you get unpolished games thrown over the wall...QA should be there as a gatkeeper, otherwise, spend your money something else.
Unfortunately, this practice is not just limited to MMOs, but is a basically the rule rather than the exception in the industry. A few development houses are trying to change that paradigm however. Though there are still those that view QA as second-class citizens and are loathe listen to them. So it's not just going to be a process and pipeline change, but also a belief and values change.


1. Typically the CS guys are not the go-to people from QA, but more people-friendly folks that can deal with customers. So why are the bug reports left for CS to compile before sending them to QA?

2. Isn't there a producer (most likely an AP) monitoring the exchange of anomalies from CS to QA to help prioritize and categorize the incoming issues?
Seems to me that this part of your workload is the most volatile. Smoke tests and sweeps should be known quantities by now (at least in man-hours). So the effects of this unknown quantity could easily toss a big ole monkey wrench into a schedule.
3. I understand that examples and workflow provided was at a high level, but it seems like there is a risk for lost data. Knowing how many people are reporting similar issues is a key piece of information, especially when prioritizing a task list.

4. QA is generally a thankless job. A whole lot of work, a ton of blame and none of the glory. It is a skilled position, and takes a certain kind of person to really understand QA and how it fits into the big picture.