Qué es el formato Given-When-Then
El formato Given-When-Then es la estructura estándar para escribir criterios de aceptación en metodologías ágiles. Given describe el contexto inicial o precondición, When especifica la acción que ejecuta el usuario o el sistema, y Then define el resultado esperado observable.
Este formato elimina ambigüedades porque obliga a pensar en términos de comportamiento verificable. Por ejemplo: 'Given un usuario logueado con rol admin, When accede al panel de estadísticas, Then visualiza métricas de los últimos 30 días'. Cada criterio debe ser independiente, testeable y expresado desde la perspectiva del usuario final, no del código interno.
Errores comunes: mezclar múltiples acciones en un When, usar Then para describir implementación técnica ('el backend llama a la API X') en lugar de resultado observable, o escribir Given demasiado vagos ('el usuario está en la app'). Un buen criterio debe poder convertirse directamente en un caso de prueba automatizado.
Cómo estructurar criterios efectivos
La calidad de un criterio depende de su especificidad medible. En lugar de 'Then el usuario ve un mensaje de éxito', escribí 'Then aparece un toast verde con el texto "Cambios guardados" durante 3 segundos en la esquina superior derecha'. Cuanto más concreto, menos espacio para interpretaciones divergentes entre desarrollo y QA.
Cada historia debería tener entre 3 y 7 criterios. Menos de 3 suele indicar que la historia es demasiado simple o está subdefinida; más de 7 sugiere que deberías splitear en historias más pequeñas. Incluí siempre al menos un criterio de caso límite (campo vacío, sin conexión, usuario sin permisos) y uno de camino feliz.
Usá datos reales en los ejemplos: en lugar de 'When ingresa un email inválido', especificá 'When ingresa "usuario@dominio" sin el .com'. Esto ayuda al equipo a visualizar exactamente qué validar. Evitá términos técnicos innecesarios: 'el modal se cierra' es mejor que 'el componente ModalWrapper ejecuta el método onClose()'.
Casos de uso en equipos ágiles
Los criterios de aceptación son el contrato compartido entre Product Owner, desarrollo y QA. Durante el refinamiento, el PO escribe los criterios iniciales y el equipo los refina: desarrollo identifica edge cases técnicos, QA agrega escenarios de validación, UX clarifica comportamientos de interfaz.
En sprint planning, los criterios sirven para estimar: una historia con 4 criterios simples es probablemente más chica que una con 6 criterios que incluyen 'sincronización con API externa'. Durante el desarrollo, cada commit o PR debería referenciar qué criterio implementa. En code review, el checklist es literal: '¿se cumplen los 5 Then especificados?'.
Para QA, cada criterio es un caso de prueba mínimo. Si tenés 5 criterios, generás al menos 5 tests (idealmente más, agregando variaciones). En la demo de sprint, el PO verifica cada criterio en vivo antes de aceptar la historia. Los criterios bien escritos eliminan el clásico 'pero yo entendí otra cosa' en la review.
Errores frecuentes y cómo evitarlos
El error #1 es escribir criterios desde la perspectiva del sistema en lugar del usuario. 'Given la base de datos tiene 50 registros' no es útil; mejor 'Given el usuario tiene 50 productos en su catálogo'. El criterio debe describir lo que el usuario percibe, no el estado interno del sistema.
Otro problema común: criterios no atómicos. 'When el usuario completa el formulario y hace click en Enviar' mezcla dos acciones. Separálas: un criterio para validación en tiempo real mientras completa, otro para el submit. Esto permite testear y desarrollar incrementalmente.
Evitá verbos ambiguos como 'gestionar', 'manejar', 'procesar'. '¿Qué significa exactamente que el usuario "gestiona" sus preferencias?' Especificá: 'When el usuario activa el toggle "Notificaciones por email", Then recibe un email de confirmación en menos de 5 minutos'. Medible, testeable, claro.
Finalmente, no uses criterios como lista de tareas técnicas ('integrar con Stripe API', 'crear tabla en DB'). Eso va en las subtasks. Los criterios describen comportamiento observable por el usuario final, punto.