QA – How Can QA Prevent Defects

As with most things, it depends. As other have pointed out, assigning blame is a good way to discourage someone and is a quick route to having someone leave your organization. Most people don't like being blamed for things all of the time and when you are writing code and it is more or less inevitable that some bugs, errors, and other random faults will slip into the code over time.

However, even pinning down a name for those bugs, errors, and other random faults can be hard as not everything is due to the code you write, if you have a buggy API (rare, but it happens) is it the developers fault or the company who wrote the API's fault? Likewise, if a random hardware fault occurs and something isn't saved correctly, is it even anyone's fault to begin with?

Generally the responsibility for correcting the issue will fall on the developers and sometimes those responsible for interfacing with the customers for the design, but responsibility for correcting the issue is not the same as being blamed for it. Generally, if someone makes a good faith effort to do something correctly, I'm not going to blame them for messing something up, although it might be a learning experience for them. Likewise, if something gets past QA and is deployed, is it QA's fault for not catching the issue ahead of time?

In terms of QA's role: they should be working with the developers and other members of them team to ensure that the final product is as stable and correct as possible.

Consolidation of defect management sounds like a good idea unless the projects are so orthogonal as to require separate defect managing systems. For instance, a solo developer doing his own testing could get by with bullet list, while a distributed organization with customers reporting bugs to a support team requires a much more heavy-weight process. This is obvious, but it is important to consider how your consolidation will effect all the developers involved and whether they will be motivated to buy into it.

The problem with bug metrics is if developers feel that bug counts are a way of measuring their performance, then they may get fudge numbers (grouping multiple bugs into one, underestimating bug impact, saying they caught the bug further upstream). This is especially a risk if you present the reports to management. Even you get support from all the developers there can be large variances simply from how they individually report bugs.

Defect containment metics, in particular seem to hold the assumption of an exponentially increasing cost curve downstream. While this may be the case, agilists make a convincing arguments for changing the cost-curve rather than stopping defects as early as possible. I would be skeptical of any metric that assumes a fixed cost-curve, since each project and type of bug may have a dramatically different cost-curves.

If it is dramatically more expensive to catch a bug downstream, then lowering the cost curve by adopting better tools, adopting continuous integration, automated testing, or other agile practices may be a better solution. Of course, in some projects there may be large unavoidable downstream costs (e.g. space shuttle code) in which case defect containment metrics make more sense.

Otherwise, useful 'metrics' in my opinion are categorizing bugs by type to help analyze any systemic flaws. Tracking where the bug was caught (development, integration, or in the field) is also important for analysis, but as I said before I would be hesitant in plugging them into a fixed cost curve to get a single number. Instead cost to fix bug can be estimated by tracking the hours a developer spends on it using a tool such as Mylyn, although this requires some discipline on the developer's part.