La respuesta de @David Hammen es muy buena, aunque no exactamente lo que hubiera dicho. Estoy de acuerdo en que Verificación responde "¿Construimos este correctamente?". Todo lo producido por un proceso puede ser verificado. La fabricación implica una verificación constante de que la cosa que se produce se ha producido correctamente.
Luego define Validación, que estamos de acuerdo es diferente, como "¿Construimos lo correcto?" Diría que la Validación se mueve en la dirección opuesta, para confirmar exhaustivamente el funcionamiento correcto correcto de un diseño. Más como "Demostrar objetivamente que la solución está diseñada correctamente". Los grados correctos de tornillos, los tamaños correctos de variables internas. Las piezas están a la altura del trabajo.
Validación de David, "¿Construimos lo correcto?" es una pregunta de alto nivel que no es algo que se pueda ejecutar contra la compilación diaria, pulgares arriba o pulgares abajo. Es un juicio de los requisitos y, en menor medida, del diseño. No es una pregunta sensata dirigida a un cuadro de texto en una pantalla o un parámetro en una API. No estoy seguro de cuál es el nombre de una palabra para la corrección de requisitos, tal vez Validación de requisitos. Prueba exhaustiva de que los requisitos corresponden a las necesidades del usuario final.
Por el contrario, mi definición de Validar es la prueba de la corrección de un diseño, las pruebas objetivas que muestran que las piezas seleccionadas harán el trabajo. El software Ariane IV que no era adecuado para Ariane V fallaría aquí, porque Ariane IV tenía un rango limitado de cambios de velocidad de ángulo. El código fue optimizado para este rango limitado, y Ariane V fue capaz de un rango más amplio de velocidades de ángulo, lo que causó el desbordamiento. Cuando ambas computadoras a bordo fallaron por desbordamiento, y lo hicieron nuevamente después del reinicio automático, se activó el sistema de destrucción.
Como dijo Dykstra, "la optimización prematura es la raíz de todo mal".
En mis definiciones, se presume que los requisitos son correctos y aceptados, validados por las pruebas de requisitos. El diseño o la validación de código demuestra que el diseño, quizás un poco de la implementación, es correcto. Todavía tiene que ejecutarse correctamente, pero confirmando que es Verificación, pruebas basadas en los Requisitos aceptados y un Diseño aceptado.
Notarás que esto se acerca dolorosamente al modelo de desarrollo de Waterfall, que parece dañino si se cree que describe sistemas complejos. Sin embargo, los Requisitos son diferentes al Diseño y el Código es una tercera cosa completamente distinta. Supongo que mi petición es que los elementos en la cascada son descripciones útiles, pero que "completo" es engañoso, por lo que lo he cambiado a "aceptado", lo que sugiere contingencia y mutabilidad.