Adam Rudd

Quality Assurance: serious business

If QA didn’t exist, we’d be dealing with some pretty shit games and software right now. Yet, for some reason, the QA portion of development in general seems like an afterthought. I have two theories about this:

1. The role of QA isn’t communicated properly OR
2. The QA process is put down as “not as important as” code/art/production/sound/design

Setting your mind up in either one of these camps is dangerous. Dangerous for the team, dangerous for the company, and dangerous for you. Here’s why:

Projects and tasks operate in cycles nowadays. You have design and production sorting out features, coders working on implementation, artists working on assets for these features, and QA verifying the correct implementation of all of this. All flow on to the other, and have communication back and forth to make sure everyone is on the same page.

The worst case scenario with this method is – after the task is completed and verified, the designers can look at it, decide it’s doesn’t work, and fix the feature so it does work (sending the cycle through again).

This system, on the whole, is pretty efficient. All tasks stay within each professional’s field, and bugs/reworks can be absorbed by the QA portion of the cycle – A well oiled team with communication and a great work ethic kicks major ass.

Now, removing Art or Code in a task cycle will very quickly set things on fire. Generally, this’ll get fixed super-quick because you just can’t get anything done without code or art. You are instantly justified by throwing a programmer at a project without a programmer because you’re screwed without one.

Removing QA on the other hand, will not give you the same knee-jerk reaction, because things won’t instantly explode on the project. This is probably more dangerous, because it’s slower and harder to spot. Kinda like the Dante’s Peak analogy by Pierce Brosnan:

You tell em Pierce!

Without this last section of the loop, resources need to be stretched to complete the loop, which can (and generally will) lead to slower implementation and late tasks.
And what’s more, RE-Implementing QA from this point will take time to kick in again, as the team is now conditioned to find bugs, and spend more time on tasks because of it (thus, turnover will be slower anyway).

QA is saving time for your more expensive guys in the project, and that means a hell of a lot if you’re employing a few seniors who are taking home an 80k+ pay packet. That additional 25% absorbing QA will fund a fulltime QA staffer with just two 80k programmers.

They are also the final line between the public and your studio. A great QA team will ensure you have no certification problems, minimal submission problems, and (best of all) no day 1 nightmares.

So, how much time will that save?