Como esta pregunta creó cierta controversia, permítanme comenzar esta respuesta con mis antecedentes: además de estar expuesto a V&V en el trabajo diario del proyecto, trabajé durante varios años en el departamento de ingeniería de software de mi alma mater y soy profesor de ingeniería de software. Si bien esto no garantiza que todo lo que digo sea correcto, espero que al menos me brinde el beneficio de la duda de que pueda haber algo de verdad en esta respuesta.
Permíteme asegurarte que no estás tan confundido como crees que estás. Lo que ha declarado en su pregunta es tan cierto como engañoso. Permítanme señalar primero lo que usted ha declarado correctamente:
- Verificación = construir el producto correcto vs validación = construir el producto correcto
- Las técnicas estáticas son parte de la verificación, principalmente porque toman su programa y algunos aportes formales derivados de los requisitos y los evalúan entre sí.
- La verificación garantiza la correcta implementación de los requisitos (es decir, que lo ha creado de la manera correcta)
Ahora déjame limpiar la confusión sobre las pruebas . Primero, como muchos comentarios han dicho antes, la prueba dinámica de código a través de pruebas automatizadas (unidad, integración, ...) es de hecho parte de la verificación. Sin embargo, lo que causa la mayor parte de la confusión es que las personas en validación también hablarán sobre las pruebas , pero significarán algo diferente: en la validación, las pruebas generalmente involucran a una persona que usa la aplicación para el propósito previsto. En el caso óptimo, este es el cliente mismo.
Sin embargo, los "errores" [1] encontrados en las pruebas de verificación y validación difieren fundamentalmente:
- errores de prueba de verificación: son errores que violan sus requisitos de una forma u otra.
- errores de prueba de validación: estos son errores con el producto que ha construido, no su funcionalidad, por lo tanto, revelan errores dentro de los requisitos.
Para la mayoría de las personas, es útil observar ejemplos concretos de diferentes casos de V&V. Los siguientes son ejemplos extremos de errores:
Tiene un requisito de bajo nivel que establece que "f (x) debería devolver x + 1" y su implementación de "f" siempre devuelve la constante 2. Puede encontrar este error mediante varios enfoques de verificación diferentes, pero su cliente probablemente ganó " No lo encuentre durante la validación, porque está construyendo un sitio de compras electrónicas y él no sabe ni se preocupa por "f".
Tiene un requisito que establece "El sistema debería poder manejar 1000 solicitudes por segundo con una carga de CPU máxima del 80%". Una vez más, la validación tendrá dificultades, tanto como la mayoría de las técnicas estáticas. De hecho, la forma más sencilla de verificar esto es probar dinámicamente su aplicación martillándola con solicitudes y monitoreando la carga de su CPU durante ese tiempo.
Considere el requisito anterior para "f" una vez más, esta vez con una implementación "correcta". Todas sus revisiones, análisis estáticos y pruebas dinámicas informarán un éxito, pero luego su cliente prueba su software y le dice que no encuentra el ícono del carrito de compras en la página web. Ninguna cantidad de verificación podrá encontrar este error, ya que lo ha hecho durante la fase de requisitos.
Como puede ver, la "prueba", si no se define con mayor precisión, es parte de la verificación y la validación, y de hecho, la "prueba" debe realizarse para ambos.
[1] "error" se usa coloquialmente aquí, para evitar la distinción entre error, falla, error, falla, ...