Can we really ship a bug-free product? That’s a tough question to answer.  Bugs originate in many places and not all bugs are the same severity.  But you can’t control what you don’t measure.  If you log and classify defects, and control the way changes are made, there may be some hope.  If not, make plans to start logging and classifying these failures.  Once you quantify this data, investigate the root cause of each failure.  Find out how it got there and what to do to prevent it next time.  Be sure to have a good change process in place to avoid introducing new bugs while trying to fix old ones.  Determine what quality level is to be achieved.  Is it expressed in defects per lines of code?  Or test failures?  Or customer complaints?  Or workarounds?  Do you have realistic goals for these measures?  Be sure to set some goals for improving the quality over time.

How do you go about finding more bugs before product release?  One way to do this might be to have a contest for the person who found the most bugs.  This would probably make folks look for problems in places that were off the beaten track but still within the users’ capability.  Naturally, you’d need some way to identify real problems from those that were due to operator mistakes, but even those mistakes could lead to product improvements and fewer field incidents. 

Let’s not only think in terms of final testing. Let’s find problems as early in the development cycle as possible… problems can begin as early as the requirements definition and they continue to propagate if not contained there.  Have another contest for the person who finds the most errors in your specifications during reviews. If you don’t already have such reviews, incorporate these steps into your development process.