Scrum: ¿Deberían mapearse los criterios de aceptación de la historia del usuario a los casos de prueba?

TL;RD

Los criterios de aceptación deben ser parte de la historia principal y ser la base para los casos de prueba. No debería haber una historia de prueba separada, ¡podrían ser una subtarea de la historia!

Respuesta larga

¿Deberían los criterios de aceptación de una historia de usuario formar la base de los casos de prueba al probar esa característica?

¡Por supuesto que deberían serlo! Tú defines qué criterios deben cumplirse para que la historia cumpla con su caso de uso. Estos criterios deben probarse para asegurarse de que la historia esté terminada. Esto significa que debe implementar diferentes tipos de pruebas (pruebas unitarias, pruebas de regresión...).

¿O debería haber una historia separada para la prueba, cuyo criterio de aceptación es que la característica que se prueba pasa la sección relevante de la especificación de la función?

La guía de Scrum es muy clara al respecto, al definir el término "Terminado": "Cada Incremento es... probado a fondo, asegurando que todos los Incrementos funcionen juntos". Lo que significa que la historia está completa, cuando se completan todas las tareas, incluidas las pruebas. ¡Así que no hay historia adicional o incluso un equipo adicional para eso!

Ejemplo

¿Cuáles podrían ser los criterios de aceptación y cómo se relacionaría esto con las pruebas?

Modifiqué el ejemplo de su historia eliminando los detalles de implementación, solo debe describirse la necesidad del cliente. El "Click-part" se ha movido a los criterios de aceptación.

Historia

Como usuario, quiero poder mostrar un mapa con la dirección reportada marcada, para poder visualizar dónde está ocurriendo el evento.

Criterios de aceptación

• Hay un botón 'Mostrar mapa' para abrir la vista del mapa (Google maps)
• La dirección reportada está marcada en el mapa.
• Si no hay una dirección marcada, el botón está deshabilitado
• ...

Estos criterios ahora deben probarse, intente pensar en escenarios soleados y errores comunes; no olvide los casos extremos.

No conozco su aplicación, así que trato de mantenerla genérica. Tiene algún tipo de prueba de usuario, donde un compañero de equipo hace clic en la aplicación y hace clic en el botón "Mostrar mapa" (aparece el mapa marcado). Otra cosa sería asegurarse de que la API de Google Maps pueda comprender el formato de su dirección (podría ser automático) o pruebe lo que sucede si Google Maps no funciona. Además, tiene algún tipo de prueba unitaria, que podría probar lo que sucede cuando el campo de dirección está vacío.

¿Cuál es la diferencia con las historias de usuario entonces?

También puede definir las siguientes historias de usuario en lugar de "criterios de aceptación":

Como usuario, quiero un botón 'Mostrar mapa' para poder abrir la vista del mapa (Google Maps) Como usuario, espero que la dirección informada esté marcada en el mapa. Como usuario, quiero que el botón 'Mostrar mapa' esté deshabilitado, cuando no hay direccion marcada

Facilita la planificación, la priorización y el seguimiento de la implementación.

La historia del usuario debe escribirse centrándose en el valor comercial en lugar de las funcionalidades.

Por ejemplo, como usuario, necesito la opción de ver la ubicación del evento en el mapa de Google para poder visualizar la ubicación.

Puede escribir características específicas que el usuario espera como críticas para la aceptación.

Por ejemplo, el mapa debería mostrarse/aparecer una vez que el usuario haga clic en el botón "mostrar mapa".

El equipo de pruebas puede probar los criterios de aceptación individuales cuando están probando la historia.

Por ejemplo, Tester puede hacer clic en el botón para verificar que el mapa muestra la propiedad.