Monday, August 27, 2007

Cardinal Rules of QA

I've been talking with a lot of non-QA types lately, and get the same question a lot.

"What's the least you need to do your job?"

This is usually coming from a VP of Engineering (aka CTO aka Director of Engineering aka CEO aka someone who thinks they want a QA department and currently has nothing). I don't think the question is intended to be mean-spirited or unusually parsimonious. Rather, I think this is an attempt to ask the real question:

"What are the universal, inviolate, cardinal rules of QA?"

This I think is an interesting question. For me there are very few things that are absolutely required to make QA feasible:

  1. A separate QA environment. You must have a safe place for QA to test. This should be in control of QA or IT, and is where all certification takes place. This is a place that isn't going to have any of the vagaries of a developer's laptop or integration machine, no old code, no incorrect libraries, etc. This is also a good clean place to test install/upgrade/deployment.
  2. A defect tracking system. What defect tracking system you use is less important than that you actually use it. When in doubt, grab a free one - Bugzilla or the like - and set it up. This doesn't have to be high overhead, but you have to have some way of knowing what you found and what you fixed.
  3. A build system. This is along the same lines as a separate QA environment. A build system is a known good place that grabs all the code from the source control system, builds it, and drops the package somewhere everyone can get at it. No manual process means no mistakes (at least, once you've gotten your build scripts right!).
  4. Source control. Just like the build system and the QA environment, the goal of this is to eliminate the unexpected things that crop up on a developer's laptop. This also gives you good things like branches and merging, so you can take what you want and not take things you don't want.
  5. A test document. This could be in Word, Excel, a database-backed test case system, doesn't matter. Just write down what you're going to test and write down what you've tested. Otherwise, you don't know what you've covered and you wind up repeating yourself.
In the end, that's it. Everything else is negotiable.

No comments:

Post a Comment