Few teams truly handle all aspects of their process well. This is not a fatal flaw, but it can be used as an indicator of the maturity of the development team. There are many fine points that should not be overlooked. Some examples, not that your team must follow, but rather are used by many teams:
n After code complete, all check-ins must have a bug number in the bug database.
n After some point in the process, every check-in must be reviewed by at least one other person (some teams make the requirement that it be a lead).
n No bug is dismissed as “non-reproducible” without consent of the test manager/lead.
n No bugs are dismissed en masse, every bugs gets a fair and honest hearing. Teams that blow off huge numbers of bugs often regret it, or read about it in InfoWorld.
n After some point, all feature/interface changes must be approved by a “change control group.”
n If the number of bugs exceeds the number that the development team can fix in a reasonable period (e.g. ten days), work on new features stops and the development and test teams work on fixing and closing bugs
These are just examples, but your team should have a list of these kinds of rules, and should be following them.