¿Cómo saber cuándo dejar de hacer pruebas?

Sé que esta es una pregunta muy muy básica. Para algunas aplicaciones de software, hay una gran cantidad casi infinitamente alta de casos de prueba para una aplicación. No es práctico probar todos esos casos de prueba. ¿Cómo decidimos cuándo detener la prueba? (aparte de "cuando se acaba el dinero").

El libro de Glenford Myers, The Art of Software Testing, tiene una regla simple pero bien basada en principios para esto: las pruebas se completan cuando ha dejado de encontrar errores. O, más prácticamente, cuando la velocidad a la que encuentra nuevos errores disminuye considerablemente.

Los errores tienden a "agruparse" en ciertos módulos y ciertas funciones: en el momento en que encuentra un error en uno, sabe que debe buscar más errores en él. Para encontrar errores, puede usar las técnicas de prueba de caja negra, prueba de caja blanca y prueba de mutación. Mientras encuentre errores, ¡sabrá que su proceso de prueba está funcionando!

Para visualizar su progreso, registre la cantidad de errores que su equipo ha encontrado por día. Si la tabla se inclina hacia abajo, entonces sabrá que las técnicas que utiliza su equipo no las encontrarán de todos modos. Por supuesto, si cree que sus técnicas no están a la altura, lea el libro de Myers y aplique los principios.

Ahora, existe la posibilidad de que te falte un parche nuevo de errores, y la tasa de búsqueda de errores habría aumentado considerablemente si hubieras seguido probando un poco más. Sin embargo, si cree que sus técnicas son sólidas, es poco probable.

La respuesta simple es que depende del sistema. Si está escribiendo un software integrado para un monitor cardíaco o herramientas de monitoreo de seguridad para un reactor nuclear, entonces el estándar es mucho más alto que si está escribiendo una plataforma de blogs.

Esta es realmente una pregunta para un buen probador del sistema (y no soy uno) pero lo intentaré.

Su medida básica será la cobertura de la prueba: qué cantidad de la aplicación realmente se ha probado (tanto por prueba unitaria como funcionalmente).

Debe evaluar cada caso de uso potencial (y los parámetros para ese caso de uso) para determinar la probabilidad de que realmente se use (por lo que puede descartar casos extremos), complejidad (las cosas más simples tienen menos probabilidades de contener errores, o más bien es menos probable que contengan elementos difíciles). para encontrar errores), el costo de la prueba (en términos de tiempo) y el impacto potencial de un defecto si se descubre en esa área (aquí es donde entra el reactor nuclear vs. la plataforma de blogs).

En función de esa evaluación, debe determinar cuáles de ellos se evaluarán y con qué detalle. Una vez que tenga una lista como esa, el equipo (incluido un gerente de producto / gerente de proyecto / representante de usuario) puede revisar esa lista y establecer prioridades según las restricciones que tenga.

Una técnica útil para pensar es que también puede variar los casos de uso que se prueban con cada versión. Por ejemplo, puede tener una lista de casos de prueba no críticos y probar la mitad de ellos con un lanzamiento y la otra mitad con el siguiente (luego alternativo). De esta manera, está aumentando la cobertura total de la prueba que obtiene por el esfuerzo (aunque a riesgo de que se introduzcan errores de regresión).

Esto también podría extenderse a las pruebas de plataforma: si admite dos bases de datos de la base de datos (o varios navegadores), pruebe la mitad de la aplicación en una, la otra mitad en la otra y luego cambie la próxima versión.

(Creo que esto se conoce como rayas, pero no me cite al respecto).

Y luego, lo último en lo que debe pensar no es en lo que prueba sino en lo que realmente soluciona cuando se descubren problemas. Es común decir "corregir todos los errores", pero la realidad es que hay presiones de tiempo y no todos los errores son iguales. Una vez más, los controles regulares de errores con todas las partes relevantes son la mejor manera de avanzar. Esto es particularmente relevante cuando una corrección de errores puede ser particularmente intrusiva ya que el trabajo adicional en las pruebas de reevaluación y prueba que genera puede superar el beneficio de la corrección.

Cuando el riesgo asociado con el uso del software se ha reducido a un nivel aceptable.

"Las pruebas de programa se pueden usar para mostrar la presencia de errores, ¡pero nunca para mostrar su ausencia!" --Edsger Dijkstra

Algo bueno a tener en cuenta al hacer cualquier prueba, automatizada o no. Solo puede probar que no ha encontrado más errores, no que ya no haya más.

Pero cuantos más ojos pongas en una sección de código, más seguro estarás de su correcto funcionamiento. Es muy parecido a la cita de Knuth sobre optimización en ese sentido: puede probar las cosas incorrectas muy fácilmente, y puede probar en los momentos incorrectos de su desarrollo.

Esencialmente, quieres estar cubierto en dos grandes lugares:

1. ¿El software pasa las pruebas de BDD que demuestran que cumple con los requisitos especificados? El software ni siquiera se puede llamar hecho si esto no es cierto.

2. ¿Los segmentos más críticos, complejos e inseguros tienen pruebas adecuadas para brindar confianza? Si se trata de un bucle central, o algo que tuvo que optimizar o piratear: realice una prueba. Si es complicado y tiene muchas divisiones lógicas: pon muchas pruebas en él. Si no puede probarlo de forma unitaria, o está incrustado demasiado profundo para probar prácticamente directamente: asegúrese de que el código haya sido revisado y el código indirectamente probado a mano.

Si espera hasta que finalice el proyecto, tendrá una gran cantidad de casos de prueba. Si realiza entregas continuamente, centrándose en entregas pequeñas, tendrá menos casos de prueba en cada iteración y podrá probar todo. Si no puede realizar entregas pequeñas, priorice y comience a realizar pruebas desde la máxima prioridad y continúe hasta que tenga que detenerse.

Si está hablando de pruebas unitarias y está haciendo TDD (escribir las pruebas primero), entonces esto no es un problema: simplemente deje de probar cuando las funciones estén listas.

En TDD incremental, escribe una prueba que falla, luego implementa la menor cantidad de código que puede hacerla pasar, luego refactoriza. Siga agregando pruebas de esta manera hasta que el método esté completo.

Aquí hay un gran ejemplo.

Los estadísticos también han analizado este problema, en realidad ya en la década de 1970-80. Dadas las suposiciones apropiadas sobre cómo se descubren los errores, intentan estimar el número de errores a partir de los datos de las pruebas. Esto se usa para determinar cuándo detenerse en función de la optimización de una función de pérdida. Consulte, por ejemplo, https://rpubs.com/hoehle/17920 ... para un breve tratamiento de uno de los documentos sobre este tema, incluido el código R sobre cómo hacerlo en la práctica.

Por supuesto, un problema siempre serán las suposiciones sobre el proceso de descubrimiento de errores. Por ejemplo, en el tratamiento anterior se supone que los errores se descubren independientemente uno del otro. En la práctica, arreglar un gran error puede, por ejemplo, causar nuevos errores, etc. Pero da un comienzo y complementa la sensación intestinal.

Cuando ha llegado la fecha de envío. No hay fin a las pruebas para un software. Pero, de nuevo, hay algo conocido como horario. Tendrá que probar la mayor parte de su funcionalidad en el tiempo programado y corregir los errores que encuentre. No hay forma de garantizar que el software sea perfecto.

Lo primero que debe probar sería la "ruta feliz", los casos límite y las entradas no válidas. Si habrá más de un usuario concurrente, deberá probar los problemas de concurrencia, como las condiciones de bloqueo y carrera. Si la aplicación usa recursos externos, deberá probar cómo se comporta la aplicación cuando esos recursos no están disponibles. Después de eso, puede usar el código para buscar cosas que puedan hacer que se rompa y probarlas. Cuando pasan todas esas pruebas, la relación costo / beneficio de las pruebas adicionales comienza a aumentar, por lo que es razonable detenerse en ese punto.

Todo se reduce a una cuestión de confianza. ¿Te sientes seguro de que el sistema se ha probado lo suficiente?

Obviamente, el "nivel de confianza" es muy subjetivo ya que nunca se puede sentir completamente seguro, pero lo suficientemente seguro, y eso es lo que estamos buscando. Para eso, debe crear una lista de indicadores, comúnmente conocida como definición de hecho y debe ser algo en lo que todo su equipo esté de acuerdo.

Aquí hay algunos "indicadores de hecho" relacionados con la prueba:

• ¿Su construcción e instalación están completamente automatizadas y todas las pruebas (unidad, interfaz gráfica de usuario, integración) se ejecutan automáticamente?
• ¿Escribe sus pruebas mientras (o preferiblemente antes) escribe el código, en lugar de después?
• ¿Te sientes lo suficientemente seguro como para hacer una refactorización de código grande sin introducir errores?
• ¿Su nivel de cobertura de código es lo suficientemente alto?
• ¿Tiene un probador dedicado en su equipo? ¿Está involucrado diariamente durante todo el desarrollo y no solo al final?
• ¿Su probador ha intentado romperlo manualmente (exploratorio) sin éxito?

Si puede verificar estos puntos, entonces probablemente pueda decir que ha probado lo suficiente.

Nunca, creo que nunca terminarás de probar en un sistema ... hay tantas variables que no puedes administrar.

Pero, como sabemos, no se puede probar "para siempre", por lo que creo que el límite depende básicamente de:

• Cuando el riesgo asociado con el uso del software se ha reducido a un nivel aceptable. (como dice @Graham Lee)
• ¿Quién es el usuario del sistema? puede ser usted o el presidente de estados unidos. En el primer caso, no le importa mucho si aparece un error porque lo resuelve y está hecho. En el segundo caso, no desea que aparezca ningún error.
• ¿Cuál es tu relación con tu cliente? Tal vez el cliente sea tu padre, por lo que no es tan terrible, o tal vez sea una gran empresa.
• ¿Qué tan grave es para los usuarios del sistema un error? ¿Causará la tercera guerra mundial o solo un mensaje feo?

Cuando las personas que tienen que cerrar sesión en la implementación están satisfechas.

o en algunos casos la mayoría de las partes responsables están satisfechas.