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, …

Indeed: verification proves that you are building the product right, while validation you build the right product.

Therefore

• verification is proving of the process… that you have followed the required standards and procedures, usually checked by static analysis and code review.
• validation is proving of the resultant product… that the code does what is required, usually checked by dynamic analysis and testing, to show that specified inputs result in specified outputs

I don’t usually cite Wikipedia, but in this case, it’s helpful…

A more detailed explaination of the two processes can be found in ISO 12207 Software Life Cycle Processes (one of the other answers posts a link to an uncontrolled copy):

7.2.4.3.2 Verification Tasks

• Requirements Verification
• Design Verification
• Code Verification
• Integration Verification
• Documentation Verification

7.2.5.3.2 Validation Tasks

• Prepare Test Requirements, Cases and Specifications
• Conduct the Tests

Now, the opening question asked why verification does not include testing. And despite some of the other answers, by P.SE members of high reputation, I put it to you that that is not the point of the verification activity, but of the validation activity.

Some answers suggest that you have to test to verify code or integration. No – that activity is to prove the modularity and the interfaces, etc, not the execution.

Utimately, what this discussion shows is that there is a lot of confusion as to what is verification and what is validation, and this is not helped by the boundary being a grey area, and defined slightly differently in different standards.

What is important is that both parts of V&V should be covered, and as long as that is the case then semantically, it doesn’t really matter whether it’s V or V… just V and V.