There's two kinds of people. Those who make LinkedIn posts claiming that most people confuse Verification and Validation with one another, and those who don't make such posts.
The first kind of people remind us that:
Verification asks "Did we build the thing right?"
Validation asks "Did we build the right thing?"
One method of verification is testing. Many people see testing as a way to show that something, like a software, has no errors. But many seasoned testers (for example Glen Myers in his classic "The Art of Software Testing") say this view is upside down. In testing, the first presumption is that the software has errors, and the purpose of testing is to uncover those errors.
So testing "fails" when it does not find errors. Testing is successful when it does find errors. The more, and them more serious, the better.
So why not take the same view for Verification and Validation? Considering that we really cannot verify full that the product was built right, in the same way that testing cannot guarantee that the software has no errors. Nor can we guarantee that "we built the right thing" but can only find evidence why it was not the right thing"
Verification - start with the assumption that we built the thing wrong somewhere find evidence of this.
Validation - start with the assumption that we built the wrong thing somewhere and finds evidence of this.
