Después de haber leído mucho sobre este tema, como en este sitio de Fundamentos de pruebas de software sobre verificación y validación y Pruebas de software y garantía de calidad: teoría y práctica de Naik y Tripathy , aún no lo entiendo. La verificación debe demostrar que está construyendo el producto correcto, mientras que la validación demuestra que ha creado el producto correcto. Pero solo las técnicas estáticas (revisiones de código, verificaciones de requisitos ...) se mencionan como métodos de verificación. ¿Cómo puede decir si está implementado correctamente si no lo prueba? Se dice que la verificación asegura que el producto cumpla con los requisitos especificados. Nuevamente, si se especifica que la función funciona de alguna manera, solo probando puedo decir que sí.
¿Alguien podría explicarme esto por favor?
fuente
Respuestas:
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:
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:
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, ...
fuente
The code implements proper event sequence, consistent interfaces, correct data and control flow, completeness, appropriate allocation timing and sizing budgets, and error definition, isolation, and recovery.yThe software components and units of each software item have been completely and correctly integrated into the software item--- ¿cómo haría cualquiera de esas cosas sin probar?De hecho: la verificación demuestra que está creando el producto correcto, mientras que la validación lo hace.
Por lo tanto
No suelo citar Wikipedia , pero en este caso, es útil ...
Se puede encontrar una explicación más detallada de los dos procesos en los Procesos del ciclo de vida del software ISO 12207 (una de las otras respuestas publica un enlace a una copia no controlada):
7.2.4.3.2 Tareas de verificación
7.2.5.3.2 Tareas de validación
Ahora, la pregunta inicial preguntaba por qué la verificación no incluye pruebas. Y a pesar de algunas de las otras respuestas, por miembros de P.SE de gran reputación, les digo que ese no es el objetivo de la actividad de verificación , sino de la actividad de validación .
Algunas respuestas sugieren que tiene para poner a prueba para verificar el código o integración. No, esa actividad es probar la modularidad y las interfaces, etc., no la ejecución.
En última instancia, lo que muestra esta discusión es que hay mucha confusión sobre qué es la verificación y qué es la validación , y esto no se ve ayudado por el límite que es un área gris, y se define de manera ligeramente diferente en diferentes estándares.
Lo importante es que ambas partes de V&V deben estar cubiertas, y siempre que sea así, semánticamente, no importa si se trata de V o V ... solo V y V.
fuente