In daily life, people will often talk about validating a fact and verifying a fact interchangeably as though they have the same meaning. In development work, including that of software testing, they have an important distinction and require a different skill set to perform.
Verification is a process of evaluating whether different components or phases in the development process have met their clearly defined specifications and technical performance targets.
Validation, on the other hand, is a potentially more subjective and crucial evaluation of the project to see if it is successfully on track to meet the needs for which it was designed, which includes satisfying the users for whom it was commissioned and complying with any regulatory guidelines.
A project that is fully verified but doesn’t validate is somewhat akin to saying “The operation was a complete success but the patient died.” However, one that is validated by a happy client but has not been professionally verified is a bit like letting an excited customer drive off in a new car whose brakes will fail on the first steep hill.
In testing and project management terms, this is an over-simplification. Both processes strive to achieve objectivity by deploying precise tools, are ongoing as the project develops, and are often guided by regulatory codes like these set out by the FDA for medical software.
Once the project model has set out its specifications, you need to prove that the program conforms to them. Whilst there are some static tools that can be used to debug and compare specification and operation of software, they cannot prove that source code will be free of fatal run-time errors in the diversity of circumstances it encounters once deployed. Fuzzing tools go some way toward simulating variable conditions, but an alternative is to recruit software testing services that can mobilise massive real-world testing through crowd-sourcing like https://www.bugfinders.com and other specialists.
Code validation can be done continuously as a project proceeds. The earlier any design errors or functional omissions are identified, the better; it’s almost always more time-consuming and expensive to correct them later. Although there are attempts to develop tools to help in this phase, it is hard to dispense with deploying beta versions, perhaps with the support of a crowd-sourcing agency.