En qué momento de una carrera de velocidad debe estar involucrado un recurso pruebas funcionales? [cerrado]

Question

Nuestro equipo de scrum de tres desarrolladores tiene un probador dedicado. En el momento en que el probador está aparentemente esperando algo para probar la mayor parte de la primera semana de nuestra 2 semanas de sprint. normalmente hacemos nuestro primer lanzamiento de la entrega de sprint alrededor del Jueves o Viernes de la semana Sprint 1. En este punto nuestro modelo de prueba puede "probar" el software embrionario.

Esto plantea la pregunta en mi mente -? Cuánto valor es la prueba funcional como esta adición, tan temprano en el desarrollo de la entrega

En esta etapa (final de la carrera corta semana 1) en el desarrollo por lo general hay errores significativos / omisiones funcionales que se pueden rectificar si la prueba fue pospuesta por sólo un par de días (2 semanas a decir del sprint).

¿Cuál es la mejor práctica en este caso?

Answer 1

Mientras que usted menciona Scrum, una buena práctica de gestión, que no describen lo que la práctica de pruebas que está utilizando.

Si estás utilizando las mejores prácticas, usted debe estar usando Test-Driven Development.

desarrollo basado en pruebas significa que la prueba se debe realizar desde el principio. Los programadores deben escribir pruebas y rellenar las clases que pasan estas pruebas.

El probador debe escribir pruebas funcionales en el día 1 , que la aplicación absolutamente no logra pasar a en el día 1 . Con el tiempo se inicia la aplicación de pasar estas pruebas y se puede llamar a su sprint de hecho.

Si usted no está haciendo desarrollo basado en pruebas, que debe ser, y su probador debe escribir casos de prueba de integración.

Si el probador no puede código, enseñarles a código. Debe tener un probador que puede codificar. Y hacer que empezar a programar las pruebas de funcionamiento en el día 1 .

Answer 2

Un probador podría estar pasando por la especificación y prueba de escritura scripts / criterios de aceptación pasos.

Como dev está llegando hasta completar una tarea, pero antes de la llegada también pueden hacer los mini revisión de las pruebas, es decir, un globo ocular de 5 minutos con el desarrollador, ya que están terminando el trabajo a menudo pueden aparecer algunos errores.

Siempre está probando la aplicación existente (suponiendo que éste no es el primer sprint de un nuevo producto) Siempre hay errores de encontrar.

Luego está el triaje de los fallos existentes, son de alta o baja prioridad.

Luego está la prueba y el cierre de los errores que los desarrolladores han fijas.

Por supuesto, el más importante es hacer café y limpiando la frente febril de cualquier desarrollador que pone su mano hacia arriba.

Answer 3

Se ha descubierto un problema con su Pila de Producto. Si usted tiene 3 desarrolladores que codifican para 3 días sin código comprobable / liberable a continuación, sus historias son demasiado grandes. Usted debe notar esto refleja este hecho en su burndown; flatline-> gran descenso al final de la carrera de velocidad. La integración debe ser una rutina diaria con una nueva funcionalidad siempre disponible para la prueba.

Answer 4

Estoy de acuerdo con lo anterior. Cuando usted elige sus historias de usuario para la primavera, que debe comenzar a definir cómo van a ser probados

Answer 5

¿Qué hay de:

• automatizar algunas de las pruebas de historia desde el último sprint que se probaron con la mano

• Automatizar la creación de los datos de prueba (y / o máquinas), de modo que es más rápido que hacer la siguiente ronda de pruebas de regresión.

• Escribir las especificaciones de prueba para algunas de las historias, de modo que los desarrolladores tienen mejor información cuando llegan a hacer esas historias.