Criterios de Aceptación Given-When-Then Explicados
Formato: Los criterios given-when-then definen comportamientos de software claros y comprobables para que el equipo tenga un entendimiento compartido.
Estructura: Cada escenario en el formato incluye el contexto, la acción del usuario y el resultado esperado en lenguaje sencillo.
Mejores Prácticas: Concéntrate en la simplicidad, la colaboración y el detalle para mejorar la claridad de los criterios de aceptación.
Errores Comunes: Evita mezclar escenarios en un solo criterio, escribir detalles técnicos y descuidar los casos límite.
Los criterios de aceptación Given-When-Then (GWT) proporcionan una forma sencilla y comprobable de describir cómo debe comportarse el software, de modo que desarrolladores, testers y partes interesadas tengan una comprensión compartida. Cuando los criterios de aceptación son vagos, los equipos pierden tiempo debatiendo requisitos, construyendo una solución equivocada y encontrando vacíos tarde en el desarrollo.
En esta guía, desglosaré el formato given-when-then, mostraré ejemplos reales en escenarios comunes, lo compararé con otros enfoques de criterios de aceptación y compartiré prácticas que ayudan a los equipos ágiles a redactar historias de usuario más claras y eficaces.
¿Qué son los criterios de aceptación Given-When-Then?
Given-when-then es una plantilla de tres partes para redactar criterios de aceptación en una historia de usuario. Cada escenario describe una faceta del comportamiento esperado en lenguaje sencillo que pueden leer desarrolladores, testers y partes interesadas.
Unlock for Free
Create a free account to finish this piece and join a community of forward-thinking leaders unlocking tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
Así es como funciona la estructura:
- Given establece lo que ya debe ser cierto antes de que el usuario final haga algo.
- When presenta la acción. Es lo que el usuario hace o el evento que activa el sistema.
- Then revela el resultado. Es la consecuencia que demuestra que el sistema respondió correctamente.
Cómo redactar criterios de aceptación Given-When-Then
Cómo redactar cada cláusula para que sea útil durante el desarrollo y las pruebas de software.
Given: Definiendo el contexto y las precondiciones
La cláusula given describe lo que ya debe ser cierto. Esto incluye el estado del sistema, el rol del usuario, las condiciones de los datos y la configuración del entorno. Las afirmaciones given sólidas son específicas. Evita escribir "Given el usuario ha iniciado sesión" cuando el escenario depende del rol. Mejor escribe "Given un cliente registrado con una suscripción válida está en la página de configuración de la cuenta".
Algunas pautas para redactar la cláusula given:
- Nombra el rol o persona de usuario cuando sea relevante.
- Indica condiciones del sistema como banderas de funcionalidades, estados de datos o conectividad.
- Combina múltiples precondiciones usando "And" en lugar de acumularlas en una sola cláusula.
When: Definir la acción o el disparador
La cláusula when captura la acción o el evento que desencadena el comportamiento que estás probando. Debe describir una interacción del usuario o un evento del sistema, no una secuencia. Usa voz activa. Escribe "When el cliente pulsa 'Aplicar cupón'" en lugar de "When se pulsa el botón de cupón". Así se elimina la ambigüedad sobre quién realiza la acción.
Mantén esta cláusula concisa. Si necesitas más de una cláusula when, probablemente estés describiendo dos escenarios distintos. Sepáralos.
Then: Especificar el resultado esperado
La cláusula then indica lo que el usuario debe observar o lo que el sistema debe hacer tras la acción. Describe resultados observables. "Then se carga el panel de control" es poco preciso. "Then el sistema muestra el panel de control del cliente en menos de dos segundos" es comprobable. Incluye detalles como mensajes de error, destinos de redirección, cambios en los datos, envíos de emails o cambios en el estado de la interfaz.
Utiliza And para encadenar múltiples resultados cuando una sola acción produce más de un resultado observable. Por ejemplo, "Then se muestra la página de confirmación del pedido" And "el cliente recibe un correo de confirmación en menos de 60 segundos."
Ejemplos Given-When-Then
Aquí tienes algunos ejemplos de criterios de aceptación given-when-then en diferentes dominios.
Inicio de sesión de usuario
Escenario 1: Inicio de sesión exitoso con credenciales válidas
Given un usuario registrado está en la página de inicio de sesión When el usuario ingresa un email válido y la contraseña correcta y hace clic en "Iniciar sesión" Then el sistema redirige al usuario a su panel de cuenta
La cláusula given aquí es deliberadamente simple porque el escenario no depende del tipo de suscripción ni del estado de la cuenta. Observa la cláusula when compuesta: introducir credenciales y hacer clic en un botón es una sola acción lógica (enviar un formulario de inicio de sesión), por eso la mantengo junta y no la divido en un escenario independiente para cada pulsación de tecla.
Escenario 2: Inicio de sesión fallido con credenciales inválidas
Dado que un usuario registrado está en la página de inicio de sesión Cuando el usuario introduce un correo electrónico válido y una contraseña incorrecta y hace clic en "Iniciar sesión" Entonces el sistema muestra el mensaje "Correo electrónico o contraseña inválidos" Y el usuario permanece en la página de inicio de sesión
La cláusula Entonces especifica el texto exacto del mensaje de error. La segunda cláusula Y es importante porque confirma que el usuario no es redirigido por error a otro lugar.
Carrito de Compras y Pago
Escenario 1: Añadir un artículo al carrito
Dado que un cliente está viendo la página de detalles de un producto en stock Cuando el cliente hace clic en "Añadir al carrito" Entonces el icono del carrito se actualiza para mostrar un artículo Y aparece un mensaje de confirmación que dice "Artículo añadido al carrito"
La cláusula dado incluye "en stock" porque el comportamiento difiere para productos agotados, y ese es un escenario aparte.
Escenario 2: Aplicando un código de descuento válido
Dado que un cliente tiene dos artículos en el carrito con un total de $80.00 Cuando el cliente introduce el código de descuento "SAVE20" y hace clic en "Aplicar" Entonces el sistema aplica un descuento del 20% Y el total del carrito se actualiza a $64.00
Las cantidades específicas en dólares evitan cualquier malinterpretación. Este tipo de escenario de descuento puede ayudar a detectar un error de redondeo en producción, donde un descuento porcentual sobre un total impar producía un precio con tres decimales. La precisión en la cláusula dado ($80.00) y en la cláusula entonces ($64.00) es lo que hace valioso al escenario.
Recuperación de Contraseña
Escenario 1: Solicitar restablecimiento de contraseña con un correo registrado
Dado que un usuario se encuentra en la página de inicio de sesión Cuando el usuario hace clic en "Olvidé la contraseña", introduce una dirección de correo registrada y hace clic en "Enviar" Entonces el sistema muestra "Se ha enviado un enlace de restablecimiento a tu correo electrónico" Y el sistema envía un correo de restablecimiento de contraseña en menos de 60 segundos
El cuando compuesto aquí representa un flujo lógico único: solicitar un restablecimiento. La restricción de tiempo de 60 segundos en la cláusula entonces es fundamental. Sin ella, un correo de restablecimiento que llegue 20 minutos después técnicamente "aprueba". Los resultados sujetos a tiempo son uno de los detalles que más frecuentemente se omiten.
Escenario 2: Usar un enlace de restablecimiento caducado
Dado que un usuario recibió un correo de restablecimiento de contraseña hace más de 24 horas Cuando el usuario hace clic en el enlace de restablecimiento en el correo Entonces el sistema muestra "Este enlace ha caducado. Por favor solicita un nuevo restablecimiento."
La cláusula dado incluye una condición de tiempo, lo que obliga a una conversación sobre cuál debe ser el periodo de caducidad.
Validación de Formularios
Escenario 1: Enviar un formulario con campos obligatorios vacíos
Dado que un usuario está en el formulario de registro Cuando el usuario deja en blanco el campo "Correo electrónico" y hace clic en "Enviar" Entonces el sistema muestra un mensaje de error en línea "El correo electrónico es obligatorio" debajo del campo de correo electrónico Y el formulario no se envía
La cláusula entonces especifica dónde aparece el error ("debajo del campo de correo electrónico"), no solo que aparece.
Escenario 2: Exceder el límite de caracteres en un campo de texto
Dado que un usuario está completando el campo "Biografía" con un límite de 500 caracteres Cuando el usuario introduce 501 caracteres Entonces el sistema impide más entradas Y aparece un mensaje que dice "Máximo 500 caracteres permitidos"
GWT vs. Listas de Verificación vs. Casos de Uso
A continuación, se presentan otros tipos de criterios de aceptación y cuándo podría usar cada uno:
| Aspecto | Given-When-Then | Lista de verificación orientada a reglas | Caso de uso |
|---|---|---|---|
| Estructura | Given, When, Then | Lista de reglas con viñetas | Pasos numerados con flujos |
| Mejor encaje | Escenarios de comportamiento, BDD | Reglas de negocio, especificaciones de la UI | Características complejas con múltiples flujos |
| Fortalezas | Testeable, automatizable, rico en contexto | Rápido de redactar, fácil de revisar | Exhaustivo, cubre casos límite |
| Limitaciones | Extenso para cambios simples | Sin flujo de escenario, difícil de automatizar | Pesado, lento de mantener |
| Público | Desarrollo, QA, producto | Producto, diseño, interesados | Equipos externos, cumplimiento |
| Alcance | Comportamiento único | Característica completa | Característica completa |
| Nivel de detalle | Tres cláusulas | Flexible | Precondiciones, postcondiciones, disparadores y pasos enumerados |
He descubierto que los casos de uso funcionan mejor cuando necesitas documentar un sistema para el cumplimiento normativo o para entregarlo a un proveedor externo. Para el trabajo cotidiano de sprint, given-when-then es más ágil y rápido.
Buenas prácticas para Given-When-Then
Aquí tienes algunas buenas prácticas para ayudarte a usar GWT de manera eficaz:
- Evita lenguaje vago o ambiguo: En lugar de “Entonces la página carga rápido”, escribe “Entonces la página de resultados de búsqueda carga en menos de dos segundos”. Sustituye adjetivos como “apropiado” o “relevante” por valores medibles. Si no puedes probarlo, reescríbelo.
- Mantén los escenarios simples y enfocados: Sigue la regla de un comportamiento por escenario. Cada escenario debe probar exactamente una cosa. Si combinas varias acciones o resultados, creas casos de prueba difíciles de depurar y mantener. Si un escenario tiene más de dos sentencias "y" en el "entonces", pregúntate si realmente estás probando una acción o dos.
- Realiza una sesión de "los tres amigos": Una sesión de tres amigos es una conversación breve y enfocada entre una persona de producto (propietario de producto o analista de negocio), un desarrollador y un tester para revisar juntas las historias próximas antes de que comience el sprint. Redactan o refinan los criterios GWT en grupo, lo que previene retrabajos.
- Mantén la coherencia de terminología y estilo: Elige términos estándar y utilízalos en todas las historias. Si usas "cliente" en un escenario y "usuario" en otro, introduces confusión. Crea un pequeño glosario si es necesario. Usa la misma estructura de frases en tus cláusulas.
Cinco anti-patrones comunes
Aquí tienes algunos errores comunes que debes evitar al redactar criterios de aceptación given-when-then:
- Escribir detalles de implementación en lugar de comportamiento: Escenarios como "Dado que la llamada a la API devuelve un código de estado 200" describen la implementación técnica, no el comportamiento del usuario. Reescribe desde la perspectiva del usuario: "Dado que el catálogo de productos se ha cargado en la página principal." Deja los detalles técnicos para el código de automatización de pruebas.
- Abarcar múltiples escenarios en uno solo: Un escenario que prueba inicio de sesión, navegación y compra en un solo bloque es una prueba de integración, no un criterio de aceptación. Divide cada comportamiento en su propio escenario. Obtendrás resultados más claros y una depuración más sencilla.
- Omitir escenarios negativos y casos borde: Los equipos de desarrollo ágil a menudo escriben el camino feliz y olvidan qué ocurre cuando algo sale mal. Por cada escenario exitoso, pregúntate: ¿qué pasa si la entrada es inválida? ¿Y si se cae la red? ¿Y si faltan datos? Escribe al menos un escenario negativo por historia para detectar problemas antes de que lleguen a producción.
- Tratar GWT como el único formato aceptable: Usa GWT para el comportamiento y usa listas de verificación para todo lo demás. Si fuerzas cada historia en given-when-then, incluyendo cambios de color de botones, actualizaciones de textos y configuraciones de infraestructura, acabarás con resultados absurdos (por ejemplo: “Dado que la página principal existe, Cuando el usuario la visualiza, Entonces la fuente del encabezado es de 16px.”).
- Escribir escenarios en aislamiento: No redactes criterios GWT en solitario. El valor del formato proviene de la conversación que genera. Si tus escenarios no están siendo discutidos por al menos dos disciplinas antes de comenzar el desarrollo de software, estás usando GWT como formato de documentación cuando su verdadero poder está en la colaboración.
¿Qué sigue?
Unos criterios de aceptación claros en formato dado-cuando-entonces son solo una parte para entregar proyectos exitosos. Amplía esa base con una membresía DPM gratuita y accede a plantillas prácticas, recursos de expertos y marcos probados que te ayudarán a convertir requisitos bien definidos en una entrega más fluida y mejores resultados.
