¿Cuál es el objetivo de las pruebas de software? [cerrado]

Habiendo leído muchos libros, hay una contradicción básica:

Algunos dicen que "el objetivo de las pruebas es encontrar errores", mientras que otros dicen que "el objetivo de las pruebas es igualar la calidad del producto", lo que significa que los errores son sus subproductos.

También estaría de acuerdo en que si las pruebas se dirigen principalmente a una búsqueda de errores, ¿quién haría la verificación real y realmente proporcionaría la información de que el software está listo?

Incluso, por ejemplo, Kaner cambió su definición original del objetivo de prueba de la búsqueda de errores a la provisión de evaluación de calidad, pero todavía no puedo ver la clara diferencia. Percibo a ambos como igualmente importantes.

Puedo verificar el software según sus especificaciones para asegurarme de que funciona y, en ese caso, los errores encontrados son solo por productos. Pero también realizo pruebas solo para romper cosas.

Además, ¿qué definición es más precisa?

_{Nota arriba Me refiero principalmente a las pruebas de software como un proceso.}

Como estoy seguro de que sabe, hay muchos tipos diferentes de pruebas de software, como pruebas unitarias, pruebas de integración, pruebas de aceptación, etc. Por lo tanto, es un término general para todos ellos, y en este nivel muy alto de discusión, solo podemos hablar realmente de "calidad", como un término amplio. Simplemente está validando el software contra cualquier medida de aceptabilidad que desee aplicar. En diferentes niveles y tipos de pruebas, estos variarán enormemente, y el único punto en común real es el aspecto de la calidad.

Los errores (como se definen tradicionalmente) son un tipo específico de problema con el software, pero hay muchos otros. A menos que estemos discutiendo un nivel de prueba específico más bajo, no tiene sentido limitar la definición a errores. ¿Es una UI que es un error demasiado lento ? ¿Qué pasa con el hecho de que olvidamos decirles a los desarrolladores que agreguen una cesta a nuestra tienda web? Quizás la confusión viene con tipos específicos de pruebas que se denominan "pruebas de software", pero en realidad es solo semántica.

Si me presionan para formalizar la definición, diría que las pruebas son un proceso de validación del software según sus requisitos (que también puede ser cualitativo). Un error es solo una violación muy específica de los requisitos (específicamente, una que el desarrollador pensó que ya funcionaba correctamente).

EDITAR: Probablemente debería agregar que la palabra "error" tiene significados muy diferentes para diferentes personas, y en realidad deberíamos comenzar esta discusión semántica definiéndola. Estoy usando la definición desde la perspectiva de un desarrollador; esto no funciona como yo (el desarrollador) lo pretendía. Por lo general, se basa en un requisito muy específico o en una interpretación muy específica de un requisito. La definición del cliente es típicamente similar: esto no funciona como yo (el cliente) lo pretendía, lo cual es muy diferente. Usando la última definición, casi podría igualar calidad y errores, porque cualquier cosa que no cumpla con los deseos del cliente es un "error".

De la respuesta de Daniel B:

Estoy usando la definición desde la perspectiva de un desarrollador; esto no funciona como yo (el desarrollador) lo pretendía. Por lo general, se basa en un requisito muy específico o en una interpretación muy específica de un requisito. La definición del cliente es típicamente similar: esto no funciona como yo (el cliente) lo pretendía, lo cual es una cosa muy diferente.

Esta es esencialmente la diferencia entre verificación y validación. La verificación responde a la pregunta "¿Lo construimos bien?" La validación responde a la pregunta "¿Construimos lo correcto?" Las pruebas de verificación y las pruebas de validación son cosas bastante diferentes. La verificación es una tarea mucho más fácil que la validación. Con la verificación, usted sabe con qué probar: los requisitos (o historias) que explican lo que se supone que debe hacer el software. Aquí hay un problema: ¿qué pasa si esos requisitos o historias están mal? ¿Cómo se prueba ese problema? Eso es lo que intenta hacer la validación.

Otro componente más utilizado en algunos círculos es el concepto de acreditación. Esto se vuelve importante cuando se reutiliza el software. Ejemplo: suponga que está construyendo una simulación de un vehículo y necesita un buen modelo de su unidad de medida inercial. Encontrará un modelo IMU existente en la biblioteca de modelos de componentes. Este modelo existente ha sido completamente verificado con los requisitos y validado con la realidad. La prueba es muy extensa e incluye comparaciones con datos de vuelo. Verificado y validado! ¡Suena bien! Solo reutilízalo como está.

Por otra parte, tal vez no. El uso previsto de ese modelo podría haber sido operaciones inactivas, su uso es modelar un cohete durante la fase de lanzamiento. El comportamiento de la IMU durante el lanzamiento será similar al comportamiento de las especificaciones: en otras palabras, pésimo. Las IMU generalmente funcionan mucho, mucho mejor que las especificaciones durante las operaciones inactivas. El uso previsto de ese modelo no coincide con el uso previsto. Será mejor que no lo reutilices. Los intentos de acreditación van más allá de la verificación y validación. Responde a la pregunta "¿Es esto lo correcto para este uso específico?"

Otro ejemplo es la primera prueba de vuelo del cohete Ariane 5. El error de software que condujo a la falla del vuelo 501 se ubica como uno de los errores de software más infames y costosos de todos los tiempos. El software de vuelo es extremadamente costoso de construir. Para evitar estos enormes costos, el software de vuelo Ariane 5 reutilizó grandes partes del software de vuelo Ariane 4. Ampliamente verificado y validado, y ya se utiliza en un entorno del mundo real. Así que solo reutilícelo como está. Incorrecto. Debería haber sido acreditado para su reutilización. Un evento supuestamente "no puede suceder" que involucró un desbordamiento de conversión de 64 bits a 16 bits sucedió y el vehículo falló como resultado.

¿Cuál es el objetivo de las pruebas de software?

En resumen: como el comentario de los autores de la pregunta dice "en general, las pruebas de software como un proceso". - Su pregunta es amplia, y aquí está su definición en el artículo de Wikipedia .

La prueba de software es una investigación realizada para proporcionar a las partes interesadas información sobre la calidad del producto o servicio bajo prueba. Las pruebas de software también pueden proporcionar una visión objetiva e independiente del software para permitir que la empresa aprecie y comprenda los riesgos de la implementación del software.

Por lo tanto, el objetivo de las pruebas de software es proporcionar información independiente sobre la calidad del producto / software. - ¿Cómo debe hacerse y subproceso de prueba de software? - Es una pregunta diferente a buscar.

Editar: El proceso de prueba de software debe proporcionarse de forma independiente según los requisitos comerciales. De lo contrario, habría menos valor en ello. De hecho, los proyectos de software de gran alcance (como los proyectos inmobiliarios nacionales o similares) tienen una oferta separada para el control de calidad, las pruebas y los procesos de verificación / aceptación de software.

Identifique regresiones de software tan pronto como se presenten.

Las pruebas unitarias, en particular, están destinadas a identificar regresiones al principio de la cadena de construcción / prueba / implementación

La prueba de aceptación se basa más en cumplir un contrato con un cliente . Pero, de nuevo, si una parte de una prueba de aceptación no pasa mientras se suponía que debía hacerlo, ha identificado una regresión para manejar.

Creo que el libro "El arte de las pruebas de software" de Glenford J. Myers lo define mejor:

"La prueba es el proceso de ejecutar un programa con la intención de encontrar errores".

Contrasta esta definición con varias definiciones comunes:

• "La prueba es el proceso de demostrar que los errores no están presentes".
• "El propósito de las pruebas es mostrar que un programa realiza sus funciones previstas correctamente".
• "La prueba es el proceso de establecer la confianza de que un programa hace lo que se supone que debe hacer".

En lugar de tratar de demostrar que un programa funciona, debemos asumir que el programa tiene errores, y el objetivo de las pruebas de software es encontrarlos. Al hacerlo, aumenta la calidad del software, que es el objetivo final de las pruebas de software.

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.

las pruebas de software no están destinadas a encontrar errores, sino a prevenir errores. Las pruebas adecuadas en las primeras etapas evitan que los errores entren en los sistemas de producción.

Creo que las inversiones en pruebas se toman para "mejorar la experiencia del usuario".

Muchas veces se dejan errores porque no afectan negativamente el uso del producto. Del mismo modo, "igualar la calidad del producto" también se desglosará por lo útil que sea trabajar en un área en particular. Por último, el criterio de "lo suficientemente bueno para enviar" debe reconocerse en que el estado final para la prueba es siempre subjetivo.

Un software con una gran calidad es, entre otras cosas, un software con 0 (o muy pocos) errores. Entonces, la búsqueda de errores es un proceso para mejorar la calidad.

Un software que cumple con todas sus características también es un software de gran calidad, por lo que probar para validar las características es un proceso para mejorar la calidad.

Un software que una buena experiencia de usuario es un software de gran calidad, etc.

Bueno, creo que el objetivo de las pruebas de software es mejorar la calidad, luego puede hacer algunas pruebas de búsqueda de errores, algunas validaciones y verificaciones de características, algunas pruebas en la interfaz de usuario, etc.