¿Es la verificación y validación parte del proceso de prueba?

Basado en muchas fuentes, no creo que la definición simple de que el objetivo de las pruebas sea encontrar tantos errores como sea posible; probamos para asegurarnos de que funciona o no. Por ejemplo, los siguientes son objetivos de probar el formulario ISTQB:

1. Determinar que (productos de software) satisfacen los requisitos especificados (creo que su verificación)

2. Demuestre que (los productos de software) son adecuados para su propósito (creo que eso es validación)

3. Detectar defectos

   Estoy de acuerdo en que las pruebas son verificación, validación y detección de defectos. ¿Es eso correcto?

Creo que lo entendiste exactamente bien.

1. La verificación y la validación son cosas diferentes y, de hecho, están bastante bien definidas. Aunque no me gusta mucho el documento, la ISO 9000ff es muy relevante para el control de calidad y define la verificación como la comparación de un producto con sus requisitos y la validación como la verificación de si realmente se ajusta a las necesidades del cliente / usuario y todos sabemos que esto puede diferir .

2. Ambos pueden hacerse a través de pruebas. La verificación llevaría a pruebas de requisitos de formulario generados. La validación lleva a la prueba realizada por Pruebas sin referencia directa a los requisitos. Creo que esto a menudo se llama prueba exploratoria. Obviamente, debe ser realizado por personas con una comprensión real de las necesidades reales de los usuarios, por lo que las pruebas alfa y beta por parte de usuarios reales son opciones obvias.

3. Sobre una base teórica, supongo que uno podría argumentar que algo cubierto por los dos primeros no es un error y, por lo tanto, encontrar errores como un objetivo separado no tiene sentido. Pero creo que hay cosas que realmente no puedes verificar o validar. Por ejemplo, seguridad: ¿cómo se valida o verifica que un sistema de software es seguro contra ataques? En cambio, intentas encontrar vulnerabilidades. Esta búsqueda no verifica ni valida nada si no encuentra problemas, pero encuentra errores si tiene éxito.

De Wikipedia: "... En otras palabras, la validación garantiza que el producto realmente satisfaga las necesidades del usuario , y que las especificaciones eran correctas en primer lugar , mientras que la verificación garantiza que el producto se haya construido de acuerdo con los requisitos y las especificaciones de diseño La validación asegura que "usted construyó lo correcto". La verificación asegura que "usted construyó correctamente". La validación confirma que el producto, según lo provisto, cumplirá su uso previsto ".

No puede probar las necesidades del usuario y verificar si las especificaciones eran correctas por código. Por lo tanto, la validación no se realiza mediante pruebas.

La verificación supone que sus requisitos y diseño son correctos, por lo que puede probarlo escribiendo un código (prueba).

Para el mundo real, las pruebas son la verificación y validación del software que cumple con los requisitos del software (comercial / funcional / no funcional). El objetivo de estos es determinar si el software es adecuado para su propósito. Cualquier comportamiento que no cumpla con los requisitos de la aplicación es un defecto, cuya gravedad deberá ser ponderada antes de determinar si el software es adecuado para su propósito.

Los defectos de baja gravedad probablemente no sean un obstáculo para pasar el software a un uso de tipo de producción. La alta gravedad puede requerir que se produzca una solución. En el mundo real, todo el software tiene defectos, algunos son problemas de codificación y otros son requisitos que faltan, lo que puede no probarse porque no puede probar requisitos desconocidos.

Hay muchas definiciones de verificación y validación. Muchas personas incluso usan la etiqueta V&V para agrupar ambas en una sola actividad. El objetivo es asegurarse de que el software haga las cosas bien y las haga bien. Ya sea para verificar el cumplimiento de los requisitos o tratar de encontrar errores no es esencial en este nivel.

La prueba es una de muchas técnicas para la verificación y validación, no al revés. La revisión del código es otra, y la verificación formal, con pruebas matemáticas, otra más.

No obstante, las pruebas deben realizarse con el objetivo de encontrar errores, no con el objetivo de verificar el cumplimiento de los requisitos.

La principal diferencia está en la mente del probador. Es mucho más fácil crear un caso de prueba que muestre que el software funciona como se esperaba (comprobar el cumplimiento), que crear un caso de prueba que muestre que el software falla (encontrar errores).

Un gran probador es un apasionado de romper el software, no de ejercitarlo de manera segura.

Veamos esto desde un punto de vista práctico. Para las pruebas, debe definir los casos de prueba. Por lo general, define los casos de prueba según los requisitos especificados, y deben cubrir los casos de "días felices" y los "casos extremos", especialmente estos últimos a menudo se definen con la intención de romper el software. Cuando algunas de sus pruebas fallan, muestran errores / defectos. Cuando tiene una cantidad razonable de casos de prueba para cada requisito, y todas esas pruebas pasan, es posible que no haya probado completamente que se cumplen todos los requisitos, pero ha mejorado la probabilidad de eso, por lo que realizó alguna verificación.

Entonces, para esa parte de la pregunta, encontrar errores y verificar puede ser solo dos lados del mismo proceso:

• las pruebas fallan: se encontraron defectos

• aprobación de las pruebas: verificación realizada (al menos, hasta cierto punto, si proporciona suficientes y las pruebas correctas)

Con respecto a la validación: como señaló @Mert, la validación se puede realizar mediante pruebas de aceptación, pero no mediante otras formas de prueba. Por lo tanto, las pruebas en general no provocan validación, solo cuando se realizan como pruebas de aceptación, por parte de algunos de los usuarios potenciales.

Todo depende de su definición de "verificación". Por ejemplo, la verificación formal generalmente no es algo realizado por un equipo de control de calidad, sino que es responsabilidad de los desarrolladores. Casi nadie hace una verificación formal debido al alto costo asociado (falta de conocimiento y recursos necesarios).

Las pruebas de software no son lo mismo que QA. Tienes razón. Las pruebas de software en general incluyen muchas etapas (humo, unidad, regresión, integración, aceptación del usuario, etc.) en sí mismas.

Por lo tanto, garantizar que el software funcione de acuerdo con los requisitos es el objetivo principal de QA (especialista en garantía de calidad, también conocido como simplemente probadores hace años). Sin embargo, no es solo una prueba . El control de calidad asegura que el conjunto adecuado de procesos para realizar el control de calidad del producto en cuestión esté en su lugar, o al menos en la fase de diseño del proyecto.

Por lo tanto, idealmente esperaría que su QA verifique la aplicación contra un conjunto de requisitos y no solo intente probarla rompiendo el software y encontrando defectos.