Test In Quality

Procedure used to "add" quality into a product after it is developed. This fails, of course because testing doesn't really add quality. It only tells you what level of quality you have achieved, which is usually poor if this was your strategy.

You can not inspect quality into the product; it is already there. - WilliamEdwardsDeming

Before I get really nailed on this, I am referring to System or Functional testing. I DO believe that you CAN TestInQuality (in a funny way) if you are writing repeatable unit tests before you write code and ensuring that they always pass at 100%.

You can test in quality if, when you say testing, you really mean testing and fixing bugs. This may not be the optimal way of building robust code, but it does work.

Not in my experience. The best you get from trying to TestInQuality is code which doesn't break for any of the tests you have run so far. My experience is that people who like this idea usually don't really understand how the program works and are just winging it. -- JeffShelby

Jeff, in my experience, this is how it always works. If you're using any Microsoft products at all, then you are using products that have had quality tested into them. Take Internet Explore 5.0 for example. It's a lot more robust than Netscape. Let me assure you that it was not anywhere near that stable when it was under development (I was at MS at the time, building an application on top of it). How did it get stable? Microsoft had dozens, if not hundreds, of testers finding bugs and entering them into the bug database. These bugs were then assigned to the appropriate developers who tracked the bugs down and fixed them. This went on for months before MS decided IE was solid enough to release. My team at MS released two 1.0 products using the same approach. Office 2000 was released using the same approach (the Office 2000 bug database had over 200 000 bug entries in it before Office shipped). My first employer used a similar approach on Aldus/Macromedia FreeHand, a product that has always had a good reputation for quality. My current employer uses the same approach. Heck, even the OpenSource guys use this approach - otherwise, they wouldn't be making the big deal about how "Debugging is parallelizable" (to directly quote Eric S. Raymond).

-- CurtisBartley

It's not common practice, but it is more effective to not put the bugs in in the first place than to rely on some independent process that tries to track down the bugs you've hidden in your code, and report them back to you, so you can fix them.

"Testing and fixing the problems you find" works. But if you really want a quality product, you'll have to build the quality in, not add it as an afterthought.

See: ItWorks

CategoryQuality