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 |
¿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
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 :-)
Hola,
ResponderEliminarPerdona, a ver si me puedes ayudar a entender porque, revisando el ejemplo, no me parece que las nuevas historias cubran todo lo que se pide en la US original. Has creado nuevas US para cubrir la sección DADO QUE, pero ninguna para la sección ENTONCES, que es la que da el resultado de ese Acceptance Criteria. Intentare explicarme a continuación, basándome en el escenario 1, aunque me parece que pasa lo mismo con los otros.
Entiendo que se han creado las 3 US basándonos en lo que se dice en la clausula Dado Que, es decir.
US1. Validar que la cuenta tiene crédito
US2. Validar que la tarjeta es valida
US3. Validar que el cajero tiene dinero disponible.
Pero a parte de la EPIC, no hay ninguna que nos diga que: la cuenta deba ser debitada, el dinero y la tarjeta entregados al cliente. Es decir, que nos faltan las siguientes:
US4, Como responsable del banco
Quiero Debitar la cuenta del cliente con el importe solicitado
Para reflejar el nuevo saldo
US5. Como responsable del banco
Quiero entregar al cliente el importe solicitado
Para cumplir con su solicitud licita de retirada de fondos
US6. Como responsable del banco
Quiero devolver la tarjeta al cliente
Para que pueda disponer de ella nuevamente