¿Una historia de usuario puede dividirse por casos/escenarios de test?

Esta estrategia es útil cuando es difícil dividir una historia de usuario únicamente en base a la funcionalidad, y se tiene que hacer en base a todos los casos/escenarios de prueba derivados de los criterios de aceptación que debe de pasar la historia. Los escenarios de prueba relevantes pueden traducirse fácilmente a historias de usuario y pueden implementarse de forma incremental.

Los escenarios de prueba en entornos automatizados suelen estar escritos en gherkin, un lenguaje creado a tal efecto para que las pruebas puedan ser entendidas tanto por los equipos de desarrollo y los técnicos como por los Propietarios del Producto, interesados de negocio, analistas e incluso el cliente.

Sintaxis gherkin para describir escenarios de prueba

Si un escenario de prueba no es muy común o no presenta un riesgo lo suficientemente alto, el Propietario del Producto puede decidir omitir la funcionalidad asociada por el momento y enfocarse en escenarios de prueba que brinden más valor. También puede decidir simplificar algún escenario de prueba para cubrir los problemas más urgentes.

¿Cuándo aplicarla?

Cuando podamos responder a la pregunta: ¿Qué escenarios tienen que ser comprobados para saber que la funcionalidad está bien implementada?

Ejemplo de una historia de usuario y sus escenarios de prueba susceptible de ser divida por esta estrategia:

Como cliente

Quiero retirar dinero del cajero automático

Para poder evitar ir al banco a hacer una cola

Escenario 1: Cuenta tiene crédito

Dado que la cuenta tiene crédito

y que la tarjeta es válida

y que el cajero tiene dinero disponible

Cuando el cliente pide dinero

Entonces la cuenta es debitada

y el dinero es entregado al cliente

y el cliente recupera su tarjeta

Escenario 2: La cuenta excede el límite negativo acordado con el banco

Dado que la cuenta excede el límite negativo acordado con el banco

y que la tarjeta es válida

Cuando el cliente pide dinero

Entonces el cajero muestra un mensaje negando el pedido

y el dinero no es entregado al cliente

y el cliente recupera su tarjeta

Escenario 3: El cliente ha iniciado la operativa en su móvil

Dado que el cliente ha introducido el importe a retirar en la App Móvil

Cuando coloca el móvil con el código QR frente al escanner del cajero

Entonces el cajero entrega el dinero directamente al cliente

La división por escenarios de prueba de esta historia genera nuevas historias:

Escenario 1:

Como responsable del banco

Quiero comprobar que la cuenta del cliente tiene crédito

Para poder no entregar dinero por error

Como responsable del banco

Quiero comprobar que la tarjeta del cliente es válida

Para poder no entregar dinero por error

Como responsable del banco

Quiero comprobar que el cajero tiene dinero disponible

Para poder asegurar la entrega del dinero

Escenario 2:

Como responsable del banco

Quiero que el cajero deniegue la entrega del dinero a través de un mensaje

Para poder evitar que la cuenta exceda el límite negativo acordado con el banco

Escenario 3:

Como cliente

Quiero iniciar la operativa de retirar dinero del cajero automático en la App Móvil

Para poder evitar hacer una cola y obtener el dinero directamente

Como podemos ver en ejemplo esta estrategia ayuda a aplicar implícitamente otras estrategias. Los escenarios 1 y 2 implican estrategia de división por reglas de negocio y el escenario 3 de división por opciones/plataformas de entrada.

My thanks to Christiaan Verwijs on who I have based and who inspired me for this post :-)