Looks to me that what have been missing in all answers is the main idea of the development process itself. What is a development process about? A development process is mainly about maturity, quality. And quality assurance is nothing but making sure the process is correctly followed. Therefore, its benefits are deeply related to having a development process.

Imagine the following scenarios:

• A building is made in an ad-hoc mode.
• A building is made by following a process.

Which building is (probably) presenting a better quality? Which one is (probably) presenting more defects?

It is no different for software development. Development process (and quality assurance) have all to do with defects, as it defines how things must be done. And that is critical when you have contributors with different expertise (and daily mood) working together. Imagine the above mentioned scenarios again. Yet this time there are several junior and intern engineers involved. What would be the implications of this in the case where there is no process involved?

From the very beginning, the development process (and quality assurance) assures that the rules are followed. And those rules avoid circumstances that might lead to defects.

I think your question boils down to semantics. The phrase “prevention of defects” doesn’t really mean anything. “Prevention of defects in the product” isn’t much more precise.

My guess (and that’s just what it is) is that when the authors say “prevention of defects in the product” they are not talking about preventing the creation of defects in any code ever. They are talking about preventing those defects ever making it into a released product.

QA can definitely aim to prevent defects making it into a released product. I don’t think it could prevent a developer from creating a defect in an internal, interim build.

QA ideally prevents defects by doing a root cause analysis on defects that have been discovered, and identifies and removes common root causes.

In the context of software development, this would be things like replacing error-prone technolgies with more mature ones, having new developers by systematically trained, ensuring that there are unit tests for the code (e.g. by tracking code coverage), conducting code reviews, or running static code analysis tools to identify areas of code that may need improvement, and ensuring that developers are given sufficient time to write unit tests and refactor bad code.

Anecdote: I’ve worked on a workflow application that supported this kind of QA at a large automobile maker. One report was “Units sold in India have the horn break unusally often”. The root cause analysis said “The horn is designed for 50,000 cycles of operation. Due to the more intensive usage in India, this is not enough”. I don’t know whether they started building more sturdy horns into cars sold in India 🙂

QA (Quality Assurance) and the corresponding QEs (Quality Engineers) are supposed to discover defects that have made it in the product before the product is released in production. Ultimately the role of the QA is to make the development team aware of the defects and the development team fixes them. In this sense QA doesn’t prevent defects but discovers them.

In another sense QA prevents future defects that would be the product of the initial defect if it is not discovered.

Reviewing specifications or any other research materials that are present before the product starts its development cycle can also help QA discover defects that would be caused by wrongly achieved general architecture of the product.

E.g. We are developing product A because we need to release feature X to the customers. However in future cycles we most certainly would have to develop a feature Y as well. So we need to adjust the architecture to not just support the feature X which we are developing, but also the future features Y and Z.

QA checks if predefined procedures are followed during the software development process. It also specifies a framework in which to define these procedures: ISO-9000, CMMi…

Thus QA ensures the quality of the process, not the quality of the product. Quality of the product is assumed to be covered by following the defined procedures.

In practice, QA brings other pairs of eyes to the project with a different point of view, and actually reveals product defects that may remain hidden otherwise.