¿Cuándo dejas de hacer pruebas?

Question

En su práctica, ¿qué medidas utiliza para saber cuándo es el momento de dejar de probar una aplicación y pasarla a producción?

Answer 1

Para proyectos en mi organización, las medidas que suelo utilizar son las siguientes:

• Sin problemas de gravedad 1 (mostrar tapón)
• Sin problemas de gravedad 2 (funcionalidad principal dañada)
• Número aceptable de problemas de gravedad 3 (funcionalidad menor)

"Número aceptable" es, naturalmente, un número muy blando, dependiendo del tamaño de la aplicación, etc.etc.

Una vez que se cumplan esas condiciones previas, celebraré una reunión con todas las partes interesadas (líder de control de calidad, líder de desarrollo, líder de soporte de aplicaciones, etc.), revisaré la lista de problemas pendientes y me aseguraré de que haya acuerdo sobre la gravedad asignada a cuestiones pendientes.Una vez que haya confirmado que no hay problemas pendientes de Sev 1 y Sev 2, recibiré llamadas de "Pasa/No pasa" de cada parte interesada.Si todos dicen "Ir", me siento cómodo pasando a Producción.Si al menos una parte interesada dice "No ir", examinamos las razones de "No ir" y, si es necesario, tomamos medidas para resolver los problemas detrás de eso.

En proyectos más pequeños, el proceso puede ser más ágil y, si se trata de una operación de una sola persona, su conjunto de condiciones previas puede ser mucho más simple, es decir,"La aplicación proporciona un beneficio razonable, aunque tiene un número (aparentemente) aceptable de errores. ¡Vamos a publicarlo!".Siempre que el beneficio proporcionado por la aplicación supere la molestia de los errores, especialmente si sigue la directriz de "liberar temprano y con frecuencia", eso podría funcionar para usted.

Answer 2

Primero, nunca dejas de probar.Cuando tú Cuando terminas las pruebas y lo publicas, lo único que significa es que tus usuarios están probando en lugar de ti.

En segundo lugar, cuando sus scripts de prueba integrales pasen con un nivel aceptable de falla, estará listo para seguir adelante.

Finalmente, esto es muy específico para su caso.En algunos proyectos, tenemos un período de prueba beta de 3 semanas en el que mucha gente piratea el sistema antes de que se pueda implementar el más mínimo cambio.En otras áreas (menos críticas), los pequeños cambios se pueden implementar con solo el visto bueno de otro desarrollador.

Answer 3

Una metodología de prueba interesante que siempre quise probar es la "siembra de errores".La idea es que una persona inserte errores intencionales en el sistema que se clasifican en diferentes categorías.

Por ejemplo:

• Errores cosméticos, ortográficos, etc.
• Errores no críticos
• Errores críticos y fallas
• Problemas de datos.No se producen errores, pero algo más profundo está mal en los resultados.
• etc.

El 'seeder' documenta exactamente lo que se cambió para insertar estos errores y poder revertirlos rápidamente.A medida que el equipo de prueba encuentra los errores sembrados, también encuentra errores reales, pero no sabe la diferencia.En teoría, si el equipo de prueba encuentra el 90% de los errores críticos sembrados, entonces probablemente haya encontrado un número proporcional de errores críticos reales.

A partir de estas estadísticas, puede comenzar a tomar decisiones sobre cuándo es aceptable tener una liberación.Por supuesto, esto no sería ni siquiera infalible debido a la naturaleza aleatoria de los errores que se encuentran (reales o sembrados), pero probablemente sea mejor que no tener idea de cuántos errores podrías estar liberando.

Answer 4

En mi lugar de trabajo, una métrica que a veces se utiliza es que hemos probado lo suficiente cuando comenzamos a encontrar errores antiguos y no reportados que han estado presentes en las últimas versiones de nuestro producto.La idea es que si esos son los errores que encontramos durante las pruebas, y esos errores han estado presentes durante años sin que un cliente se haya quejado de ellos, entonces probablemente podamos enviarlos con seguridad.

Por supuesto, también tiene todas las pruebas manuales, pruebas automatizadas, hacer que los desarrolladores utilicen el producto, versiones beta y pruebas continuas, pero usando cuántos errores estamos encontrando ahora que han estado presentes, pero no informados, en versiones anteriores. Fue una idea nueva para mí cuando la escuché por primera vez.

Answer 5

Cuando todos los principales obstáculos del espectáculo hayan desaparecido.

En serio, deberías hacer una prueba de aceptación del usuario y dejar que tus usuarios utilicen tu sistema y descubrir si todo está listo para ellos.Si esto no es práctico, realice una versión beta cerrada con usuarios seleccionados que se parezcan a su público objetivo.

Es imposible encontrar realmente todos los errores en su sistema, por lo que a veces la única regla real es solo envíalo.

Answer 6

mharen,

Encuentro que si tienes pruebas automatizadas integrales, es completamente irresponsable enviar software a menos que todo de ellos pasan.Las pruebas automatizadas significan que estas son áreas que son funcionalidades principales o errores que han ocurrido en el pasado y que usted conoce y que puede corregir para aprobar la prueba.Será irresponsable enviar software que no pase el 100% de sus pruebas automatizadas.

Answer 7

jon,

No quise decir que los scripts de prueba implicaran automatizado pruebas.Me refería al enfoque más tradicional de una lista paso a paso de qué probar y cómo probarlo.

Dicho esto, no estoy de acuerdo en que se deba exigir la aprobación de todas las pruebas automatizadas.Todo depende de la gravedad y la prioridad.En un proyecto grande, podemos hacer que los desarrolladores escriban pruebas que fallen en función de los problemas informados por los usuarios.Dado que no podemos corregir todos los errores con cada versión, es un hecho que algunas pruebas simplemente no pasarán.

Answer 8

Medir la cantidad de tiempo de prueba invertido en el producto entre "showtopper" o errores de funcionalidad importantes puede permitirle saber que ya casi ha llegado.En momentos de rápido cambio en el producto con la incorporación de nuevas funciones, es común que un equipo de pruebas descubra que la mayoría de los errores que informan son errores de funcionalidad graves.A medida que se solucionan, a menudo hay una gran cantidad de problemas menores, de ajuste y acabado, destinados a mejorar la fluidez y claridad de la interacción;en conjunto marcan una gran diferencia en la calidad del producto, pero cada uno de ellos no es muy importante.A medida que se solucionen y continúen las pruebas, probablemente seguirá recibiendo informes de errores a medida que los evaluadores detecten casos de error y patrones de uso inusuales.En ese punto, depende de cuándo se ve el valor comercial de la publicación frente al riesgo de que se produzcan obstáculos no detectados.