domingo, 14 de junio de 2020

¿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 :-)

No hay comentarios:

Publicar un comentario