As this question created some controversy, let me start off this answer with my background: Apart from being exposed to V&V in daily project work, I worked for several years in the software engineering department of my alma mater and am a lecturer for software engineering. While this does not guarantee that anything I say is correct, I hope it at least gives me the benefit of the doubt that there might be some truth in this answer.
Let me assure you, that you are not as confused as you may believe you are. What you have stated in your question is as much true as it is misleading. Let me first point out, what you have correctly stated:
- Verification = build the product right vs validation = build the right product
- Static techniques are part of verification - mainly because they take your program and some formal input derived from the requirements and evaluate them against each other.
- Verification ensures correct implementation of the requirements (i.e. that you have built it the right way)
Now let me clean up the confusion about testing. First, as many comments have stated before, dynamic testing of code via automated tests (unit, integration, ...) is indeed part of verification. What causes most of the confusion, however, is that people in validation will talk about testing as well, yet mean something different: in validation, testing usually involves a person using the application for its intended purpose. In the optimal case, this is the customer him-/herself.
However, the "errors" [1] found by testing in verification and in validation differ fundamentally:
- verification testing errors: these are errors that violate your requirements in one way or another.
- validation testing errors: these are errors with the very product you have built, not its functionality, hence, they reveal errors within the requirements.
For most people, it helps to look at concrete examples of different V&V cases. The following are extreme examples of errors:
You have a low-level requirement that states "f(x) should return x+1" and your implementation of "f" always returns the constant 2. You may find this error by several different verification approaches, but your customer probably won't find it during validation, because you are building an e-shopping site and he neither knows nor cares about "f".
You have a requirement that states "The system should be able to handle 1000 requests per second at a CPU load maximum of 80%". Again, validation will have a hard time, just as much as most static techniques. In fact, the simplest way to verify this is to dynamically test your application by hammering it with requests and monitoring your CPU load during that time.
Consider the above requirement for "f" once more, this time with a "correct" implementation. All your reviews, static analysis and dynamic tests will report a success, but then your customer tests your software and tells you that he misses the shopping cart icon on the webpage. No amount of verification will be able to find this error, as you have made it during the requirements phase.
As you can see, "testing" - if not defined more precisely - is part of both verification and validation, and in fact, "testing" should be performed for both.
[1] "error" is used colloquially here, so as to avoid the distinction between error, failure, mistake, fault, ...
