I think you got it exactly right.

1. Verification and Validation are different things and are in fact pretty well defined. Although I don’t like the document very much the ISO 9000ff is highly relevant for QA and defines Verification as comparing a product with its requirements and Validation as checking if it actually fits the needs of the customer/user and we all know this can differ.

2. Both can be done through testing. Verification would lead to tests generated form requirements. Validation leads to test done by Tests without direct reference to requirements. I think this is often called explorative testing. Obviously it must be done by people with a real understanding of the real needs of the users, so alpha and beta testing by real users are obvious options.

3. On a theoretic basis I guess one could argue anything covered by the first two isn’t a bug and therefore finding bugs as a separate goal doesn’t make sense. But I think there are things that you can’t really verify or validate. For example security: How do you validate or verify that a software system is safe against attacks? Instead you try to find vulnerabilities. This search doesn’t verify or validate anything if it fails to find problems, but it finds bugs if it succeeds.

From Wikipedia : “… In other words, validation ensures that the product actually meets the user’s needs, and that the specifications were correct in the first place, while verification is ensuring that the product has been built according to the requirements and design specifications. Validation ensures that “you built the right thing”. Verification ensures that “you built it right”. Validation confirms that the product, as provided, will fulfill its intended use.”

You can’t test user’s needs and check if the specifications were correct by code. So validation is not done by testing.

Verification supposes that your requirements and design are correct, so you can test it by writing code(testing).

For the real world, testing is verification and validation of the software that is meets the software’s requirements (business/functional/non-functional). The aim of these is to determine if the software is fit for purpose. Any behavior that does not meet the requirements of the application is a defect – the severity of which will need to be weighted up before determining if the software is fit for purpose.

Low severity defects are probably not show-stoppers to passing the software onto a production type use, High severity may require a fix to be produced. In the real world all software has defects, some are coding issues and others are from missing requirements – which may not be tested for because you cannot test a unknown requirements.

There are many definitions of verification and validation. Many people even use the V&V tag to group both in a single activity. The aim is to make sure that software makes right things and makes things right. Whether it is to check compliance with requirements or try to find bugs is not essential at this level.

Testing is one out of many techniques to verification and validation, not the other way. Code review is another one, and formal verification, with mathematical proofs yet another one.

Nonetheless, testing should be performed with the aim to find bugs, not with the aim to check compliance with requirements.

The main difference is in the mind of the tester. It is far easier to build a test case showing that sofware works as intended (checking compliance), than to build a test case showing that software fails (finding bugs).

A great tester is passionate about breaking software, not about exercizing it in a safe way.

Lets see this from a practical point of view. For testing, you need to define test cases. Typically, you define test cases along the specified requirements, and they should cover “happy day” cases as well as “edge cases” – especially the latter are often defined with the intention of breaking the software. When some of your tests fail, they show up bugs/defects. When you have a reasonable amount of test cases for each requirement, and all that tests pass, you may not have fully proven that all requirements are fulfilled, but you have improved the probability for that, thus done some verification.

So for that part of the question, finding bugs and verification may be just two sides of the same process:

• tests fail: defects found

• tests pass: verification done (at least, to some degree, if you provide enough and the right tests)

Concerning validation: as @Mert pointed out, validation can be done by acceptance testing, but not by other forms of testing. Thus testing in general causes no validation, only when done as acceptance testing, by some of the potential users.

It all depends on your definition of “verification”. For example, formal verification is usually not something done by a QA team, but is instead a responsibility of the developers. Almost nobody does formal verification because of the high cost associated with it (knowledge gap and resources needed).

Software testing is not same as QA. You got that right. Software testing overall includes many stages (smoke, unit, regression, integration, user acceptance, etc. ) in itself.

Thus, to assure that software works in accordance to the requirements is the man goal of QA (quality assurance specialist – aka used to be simply called testers years ago). However, it is not just testing. QA ensures that proper set of processes to perform quality check of the product in question are in place, or at least taken into design phase of the project.

Thus, ideally you would expect your QA to verify the application against set of requirements and not just try to test it by breaking the software and finding defects.