¿En qué momento se prueba una historia de usuario en una iteración?

TL;DR

Es probable que tenga este problema porque las pruebas no se incluyen en su "definición de hecho" para cada historia. Debe incluir pruebas para cada historia en su Sprint Backlog y como una columna en su kanban si usa uno.

Prueba como un requisito de la historia

En general, los equipos de Scrum incluirán pruebas unitarias en el trabajo de desarrollo y Garantía de calidad (QA) o Pruebas de aceptación del usuario (UAT) como un paso de proceso definido antes de que una historia pueda considerarse completa.

Al descomponer historias para el Sprint Backlog, puede ser útil agregar una tarea explícita para QA/UAT al backlog de cada historia. Esto lo convierte en un elemento de la lista de verificación, y cualquier historia que no haya completado esta tarea al final del Sprint se cuenta como incompleta.

En muchos casos, los equipos experimentados no incluyen las pruebas como un elemento explícito porque están integrados en sus estimaciones y forman parte de la "definición de hecho" del equipo. En tales casos, la prueba es un requisito implícito para que una historia se considere completa, pero se aplica la misma regla: si no se ha hecho la prueba, entonces la historia está incompleta.

Además, muchos profesionales ágiles usan kanbans para rastrear historias a través del flujo de trabajo del equipo. Tener columnas únicas para probar las historias que deben pasar antes de colocarse en la columna "terminado" garantiza que haya un recordatorio visual de que la prueba es intrínseca al proceso.

Finalmente, debido a que las pruebas deben ser parte de la definición de hecho , se deben incluir búferes adecuados para las pruebas en las estimaciones de su historia. Cuando los evaluadores no participan en las sesiones de planificación, o cuando las pruebas no forman parte de la definición formal de hecho , es posible que se pase por alto esta práctica esencial.

Cuándo probar

Las pruebas deben entrelazarse a lo largo de su proceso. Los evaluadores deben:

1. Participar en la planificación de Sprint y la estimación de la historia.
2. Trabaje con los desarrolladores para identificar y crear pruebas durante el desarrollo de funciones.
3. Trabaje con los redactores técnicos para crear pruebas que actúen como autodocumentación del producto.
4. Tener su propio paso de proceso o columna kanban a través de la cual fluyen las historias durante cada iteración.
5. Participe activamente en el stand-up diario para coordinarse con los desarrolladores, los escritores técnicos y otros miembros del equipo.
6. Levantar tareas bloqueadas durante el stand-up diario.
7. Plantear problemas de proceso (como esperar hasta el final del Sprint para realizar la prueba) durante las Retrospectivas del Sprint.

Si las pruebas se vuelven parte integral del proceso de su equipo, es menos probable que requiera pruebas de última hora al final de cada iteración. Además, debido a que las pruebas son una responsabilidad del equipo , todos los miembros del equipo deberán participar en las tareas de prueba que están atrasadas para completar las historias al final de cada Sprint.

Cree un fuerte incentivo para que todo el equipo sea consciente de los requisitos de recursos y tiempo para las pruebas, tanto durante la planificación como durante cada iteración. Si hace eso, las pruebas dejarán de ser algo que se "arroja por encima de la pared" a los evaluadores al final.