I was reading through Michael Russell's coverage of his interview at Sony. He was applying to be a QA lead/manager. Wow. I mean I knew lots of places cut corners when it comes to QA, but I didn't realize that one of the most important game companies in the world did. It's absolute crazy talk to only have more than two QA guys on projects of those size for the last two weeks. Dear God.
major friction between test and development teams with little to no management backing for test, little to no shared technology, extremely lax "user effect" bug metrics for determining whether or not to fix something, and a variety of other fairly hefty issues, not just from a process standpoint, but a overall culture standpoint. Microsoft is known for giving QA a bit too much say in the products that are developed, but the feeling I got inside Sony was that QA was seen as nothing but a bunch of monkeys with controllers.
The emphasize is mine. If you've worked in the software (games, business or otherwise) industry for any amount of time you'll most assuredly have found places where QA is an after thought, a necessary evil, but definitely unloved by all developers and managers. Of course, if you've worked in the industry long enough, you'll have found that lax QA policies such as that can absolutely sink a project. If you treat your testers as nothing but monkeys with controllers you'll find they give about that level of quality in thoroughness and bug reporting.
To be fair, I've heard of projects that get away with very few QA guys on large projects and somehow manage to do a good job. I think that's because that QA team is damn good AND they are respected as a valuable part of the process. If you're looking at your QA as something to do last minute, you're going to get bit by it sooner or later. Whether that's in a production product that has a lot of bugs or in deadlines that are continually missed, it'll get ya.
I also didn't realize anyone worked like this with their QA team.
I was told that the way that Sony tests their games is that there are one or two test leads on a project starting at about six months out. At T-8 weeks, between 80 and 100 temporary testers are brought on to test the game for those eight weeks. That's it. This was done for financial reasons, and as a QA Manager, I would be expected to run test the same way. Obviously, I didn't feel that was a valid way of handling QA.
That's insane. Not only are you actually then hiring the afore mentioned monkeys with controllers, you're QA process is going to be total hit or miss. Your bug reports are going to be a joke and the level quality you'll be getting will be scary. Michael gives some really good reasons why not do this in another article.
-
Here's my little rant on QA:
How should the QA process work, you ask? Well, that depends on the size of the project, of course. But it should go something like this…
Developers/Designers work on project technical documents. When the documents are ready, the QA lead checks it over (you can often fine flow, UI, etc problems in a tech doc) and gives his approval (after any needed fixes, of course). Then the developer starts developing. He releases parts of the projects at a time after, and this is the key point, he/she thoroughly tests the piece/product. Not before. Then the QA team gets it and puts it through black box testing, UI flow testings, tech doc comparison testing, etc, etc (all depending upon the type of project and software, of course). Any bugs found are submitted into a bug tracking system with explicit, detailed information where and how to reproduce the problem, maybe they have suggest priority. Then a project manager type (often more than one) will set the actual priority, assign the bugs to a specific team/person and the process will start over.
And that's a very simplistic version geared towards a smaller company environment. Add resources, people, levels of designers, analysts, etc as needed.
The biggest thing to me in that process? Developers testing their own code before they do anything else with it. Many developers miss this point. MANY. I'm off the opinion all developers should work in QA at some point, learn the methodologies so they can be half way decent (at the least) testers of their own code. So many developers that I've worked with have skipped that point. I've worked with developers 6 years in the industry that don't test their own code. What a fricking nightmare.
What Would Matt Do: Honor QA as something not only necessary, but useful. Treat the QA process with respect, as much respect as the other parts and your product will be that much better because of it.