Also according to Software Testing By Srinisvasan Desikan, Gopalaswamy Ramesh or ISTQB text books. Quality assurance is e.g. reviewing products, inspections, walkthroughs to see if all standards are being followed. This is preventive activity. I cannot see how this can be preventive?

For the references:

defect prevention (Quality Assurance)

Software Testing By Srinisvasan Desikan, Gopalaswamy Ramesh

Quality Assurance (QA) tries to go one step further. Instead of concentrating on post- facto defect detection and correction, it focusses on the prevention of defects from the very start.

Managing Global Software Projects - Page 110

QA deals with prevention of defects in the product being developed.

Software Testing and Quality Assurance

  • 2
    QA can't "prevent" defects. Defects (bugs) are introduced by developers, testers are expected to discover and report these, as well as verify fixes when developers claim particular bug is fixed
    – gnat
    Commented Nov 22, 2012 at 9:57
  • Then I would suggest you to read some books about the topic. It is kinda common perception.
    – John V
    Commented Nov 22, 2012 at 10:09
  • 1
    BTDTGTTS. Have read a lot of books. Also been a tester (then test lead, test architect) in a professional software company for a few years. Neither did "prevention" myself, nor even been required to. Can't even recall this idea from books I've read. Also, you didn't quote from where word "preventive" appeared in the body of your question. Without references, it looks like you just imagined it sorry
    – gnat
    Commented Nov 22, 2012 at 10:15
  • 1
    Alright, here are few examples. defect prevention (Quality Assurance) - quote from the book I mentioned in the post. Section 1.11. "Quality Assurance (QA) tries to go one step further. Instead of concentrating on post- facto defect detection and correction, it focusses on the prevention of defects from the very start." Managing Global Software Projects - Page 110.I think you are missing the point that QA can set standards (e.g.each function will be mapped to a Use case) and thus it would be hard for a developer to miss a function-it would be revelaed during inspection, not just during testing.
    – John V
    Commented Nov 22, 2012 at 10:22
  • 2
    @gnat: QA can most definitely prevent defects by removing or mitigating some of the circumstances that result in developers introducing bugs. Commented Nov 22, 2012 at 11:53

5 Answers 5


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.

  • Thank you. One thing that still confuses me that some sources consider inspections, reviews, walkthroughs to be QA, some consider it to be Quality Control (like testing).
    – John V
    Commented Nov 22, 2012 at 13:02
  • As I see, those could be tools for both processes. A peer review focus on the product (QC). An audit review (probably made by a process expert) focus the process (QA).
    – rvcoutinho
    Commented Nov 22, 2012 at 13:21
  • You should also be aware that most sources present examples on how to perform a certain process/activity. Nonetheless, there are infinity possibilities and tools (that might not have been mentioned) that could be used in order to implement those processes.
    – rvcoutinho
    Commented Nov 22, 2012 at 13:25
  • That is the problem, they explicitly mention peer review as QA (preventing from defects to be build into software)..but some do not.
    – John V
    Commented Nov 22, 2012 at 13:32
  • Unanimity is hard to find. But if you follow those best practices, the name of the process (or discipline) is not going to matter.
    – rvcoutinho
    Commented Nov 22, 2012 at 13:37

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 :)

  • 1
    I tend to disagree. Not with what you have experienced, of course. But the root cause analysis is not part of the QA process. This is more likely to be included in a software improvement process. The QA would only consider those root causes if they were a root for a process improvement (as quality assurance focus at the process).
    – rvcoutinho
    Commented Nov 22, 2012 at 12:06

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.

  • But doing the reviews, inspections, walkthroughs (which I would say is Quality Control) is said to be preventive, as defects are discovered earlier than during the testing.
    – John V
    Commented Nov 22, 2012 at 9:45
  • @user970696 I have made a slight update to my post. Commented Nov 22, 2012 at 9:53

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.

  • Thanks. But isn't reviewing, walkthroughs etc. then quality control (as some books say) because you actually work with the product, not a process?
    – John V
    Commented Nov 22, 2012 at 9:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.