10 min lectura • Guide 799 of 877
Redacción de Criterios de Aceptación
Los criterios de aceptación claros alinean las expectativas de todo el equipo. GitScrum ayuda a rastrear el cumplimiento de criterios y garantiza que nada se pase por alto antes de marcar una historia como completada.
Fundamentos de Criterios de Aceptación
Propósito
POR QUÉ IMPORTAN LOS CRITERIOS DE ACEPTACIÓN:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SIN CRITERIOS CLAROS: │
│ ───────────────────── │
│ Desarrollador: "Creo que está terminado" │
│ PO: "Eso no es lo que quería decir" │
│ Desarrollador: "De vuelta al principio..." │
│ → Retrabajo, frustración, retrasos │
│ │
│ CON CRITERIOS CLAROS: │
│ ───────────────────── │
│ Desarrollador: "Todos los criterios cumplidos y verificados"│
│ PO: "Perfecto, vamos a publicarlo" │
│ → Correcto a la primera, todos alineados │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ LOS CRITERIOS DE ACEPTACIÓN DEFINEN: │
│ ───────────────────────────────────── │
│ │
│ LÍMITES: │
│ Qué está dentro y fuera del alcance │
│ "Restablecer contraseña solo por email (no SMS)" │
│ │
│ COMPORTAMIENTO: │
│ Cómo debe funcionar la característica │
│ "Muestra error si el email no se encuentra" │
│ │
│ CONDICIONES: │
│ Casos extremos y escenarios especiales │
│ "El enlace expira después de 24 horas" │
│ │
│ RESULTADOS MEDIBLES: │
│ Rendimiento, accesibilidad │
│ "La página carga en menos de 2 segundos" │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ BUENOS CRITERIOS SON: │
│ ───────────────────── │
│ ✅ Verificables (se puede comprobar sí/no) │
│ ✅ Claros (sin ambigüedad) │
│ ✅ Concisos (no una novela) │
│ ✅ Independientes (se puede probar cada uno) │
│ ✅ Enfocados en el resultado (no implementación) │
└─────────────────────────────────────────────────────────────┘
Formatos de Escritura
Formato Dado-Cuando-Entonces
FORMATO DADO-CUANDO-ENTONCES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ESTRUCTURA: │
│ ─────────── │
│ DADO [precondición/contexto] │
│ CUANDO [acción/disparador] │
│ ENTONCES [resultado esperado] │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ EJEMPLO: Restablecimiento de Contraseña │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ HISTORIA: Como usuario, quiero restablecer mi contraseña││
│ │ ││
│ │ CRITERIOS DE ACEPTACIÓN: ││
│ │ ││
│ │ 1. DADO que estoy en la página de inicio de sesión ││
│ │ CUANDO hago clic en "Olvidé mi contraseña" ││
│ │ ENTONCES veo el formulario de restablecimiento ││
│ │ ││
│ │ 2. DADO que ingresé un email registrado ││
│ │ CUANDO envío la solicitud de restablecimiento ││
│ │ ENTONCES recibo un email en menos de 1 minuto ││
│ │ ││
│ │ 3. DADO que ingresé un email no registrado ││
│ │ CUANDO envío la solicitud de restablecimiento ││
│ │ ENTONCES veo "No existe cuenta con este email" ││
│ │ ││
│ │ 4. DADO que hago clic en el enlace del email ││
│ │ CUANDO establezco una nueva contraseña ││
│ │ ENTONCES puedo iniciar sesión con la nueva contraseña││
│ │ ││
│ │ 5. DADO que el enlace tiene más de 24 horas ││
│ │ CUANDO hago clic en el enlace ││
│ │ ENTONCES veo "Enlace expirado, solicita uno nuevo"││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ BENEFICIOS: │
│ • Estructurado y consistente │
│ • Fácil de convertir en pruebas automatizadas │
│ • Precondiciones claras │
└─────────────────────────────────────────────────────────────┘
Formato de Lista de Verificación
FORMATO DE LISTA DE VERIFICACIÓN:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ESTRUCTURA: │
│ ─────────── │
│ Lista simple de condiciones que deben cumplirse │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ EJEMPLO: Página de Perfil de Usuario │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ HISTORIA: Como usuario, quiero ver mi perfil ││
│ │ ││
│ │ CRITERIOS DE ACEPTACIÓN: ││
│ │ ││
│ │ ☐ El perfil muestra nombre, email y avatar ││
│ │ ☐ El avatar muestra iniciales si no hay imagen ││
│ │ ☐ Botón editar visible solo para perfil propio ││
│ │ ☐ Se muestra la fecha del último inicio de sesión ││
│ │ ☐ La página carga en menos de 2 segundos ││
│ │ ☐ Funciona en dispositivos móviles (responsive) ││
│ │ ☐ Accesible mediante navegación por teclado ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ BENEFICIOS: │
│ • Rápido de escribir │
│ • Fácil de revisar en demos │
│ • Verificación simple de pasa/no pasa │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ CUÁNDO USAR CADA UNO: │
│ ───────────────────── │
│ │
│ DADO-CUANDO-ENTONCES: │
│ • Interacciones de usuario complejas │
│ • Muchos casos extremos │
│ • Se convertirán en pruebas automatizadas │
│ │
│ LISTA DE VERIFICACIÓN: │
│ • Características más simples │
│ • Requisitos no funcionales │
│ • Se necesita verificación rápida │
└─────────────────────────────────────────────────────────────┘
Patrones Comunes
Criterios por Tipo
PATRONES DE CRITERIOS DE ACEPTACIÓN:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CAMINO FELIZ: │
│ ───────────── │
│ El escenario principal de éxito │
│ "Cuando el usuario ingresa datos válidos, se crea el registro"│
│ │
│ MANEJO DE ERRORES: │
│ ────────────────── │
│ Qué sucede cuando las cosas salen mal │
│ "Cuando el email es inválido, muestra mensaje específico" │
│ │
│ CASOS EXTREMOS: │
│ ─────────────── │
│ Condiciones límite │
│ "Cuando hay 0 artículos en el carrito, muestra mensaje vacío"│
│ "Cuando hay más de 100 artículos, muestra paginación" │
│ │
│ PERMISOS: │
│ ───────── │
│ Quién puede hacer qué │
│ "Solo el administrador puede eliminar usuarios" │
│ "Los usuarios solo pueden editar su propio perfil" │
│ │
│ RENDIMIENTO: │
│ ──────────── │
│ Requisitos de velocidad y escala │
│ "La búsqueda devuelve resultados en menos de 500ms" │
│ "Soporta 1000 usuarios concurrentes" │
│ │
│ ACCESIBILIDAD: │
│ ────────────── │
│ Requisitos de diseño inclusivo │
│ "Todos los formularios navegables por teclado" │
│ "Las imágenes tienen texto alternativo" │
│ │
│ SEGURIDAD: │
│ ────────── │
│ Requisitos de protección │
│ "Contraseñas almacenadas hasheadas, no en texto plano" │
│ "La sesión expira después de 30 min de inactividad" │
└─────────────────────────────────────────────────────────────┘
Ejemplo Completo
HISTORIA COMPLETA CON CRITERIOS DE ACEPTACIÓN:
┌─────────────────────────────────────────────────────────────┐
│ │
│ HISTORIA-456: Checkout del Carrito de Compras │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ COMO cliente ││
│ │ QUIERO completar el checkout ││
│ │ PARA recibir mi pedido ││
│ │ ││
│ │ ═══════════════════════════════════════════════════════ ││
│ │ ││
│ │ CRITERIOS DE ACEPTACIÓN: ││
│ │ ││
│ │ REVISIÓN DEL CARRITO: ││
│ │ ☐ Muestra todos los artículos con nombre, precio, cantidad││
│ │ ☐ Permite modificar cantidades (1-99) ││
│ │ ☐ Permite eliminar artículos ││
│ │ ☐ Muestra subtotal, impuestos y total ││
│ │ ││
│ │ ENVÍO: ││
│ │ ☐ El formulario de dirección valida campos requeridos ││
│ │ ☐ El código postal valida el formato ││
│ │ ☐ Muestra opciones de envío con precios ││
│ │ ☐ Guarda dirección para futuros pedidos (opcional) ││
│ │ ││
│ │ PAGO: ││
│ │ ☐ Acepta Visa, Mastercard, Amex ││
│ │ ☐ El número de tarjeta valida con algoritmo Luhn ││
│ │ ☐ CVV requerido y oculto ││
│ │ ☐ Muestra icono del tipo de tarjeta según número ││
│ │ ││
│ │ CONFIRMACIÓN: ││
│ │ DADO carrito válido, envío y pago ││
│ │ CUANDO el cliente hace clic en "Realizar Pedido" ││
│ │ ENTONCES se crea el pedido y muestra confirmación ││
│ │ Y se envía email de confirmación en menos de 1 minuto ││
│ │ ││
│ │ MANEJO DE ERRORES: ││
│ │ ☐ Fallo de pago muestra "Pago rechazado" ││
│ │ ☐ Permite reintentar pago sin re-ingresar datos ││
│ │ ☐ Artículos sin stock bloqueados con mensaje ││
│ │ ││
│ │ NO FUNCIONALES: ││
│ │ ☐ Flujo de checkout completo en menos de 3 clics ││
│ │ ☐ Funciona en dispositivos móviles ││
│ │ ☐ Carga de página menor a 2 segundos ││
│ │ ││
│ │ FUERA DE ALCANCE: ││
│ │ • PayPal (historia separada) ││
│ │ • Tarjetas de regalo (historia separada) ││
│ │ • Múltiples direcciones de envío ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Errores Comunes
Antipatrones
ANTIPATRONES EN CRITERIOS DE ACEPTACIÓN:
┌─────────────────────────────────────────────────────────────┐
│ │
│ DEMASIADO VAGO: │
│ ─────────────── │
│ ❌ "El formulario debe ser fácil de usar" │
│ ❌ "El rendimiento debe ser bueno" │
│ ❌ "Manejar errores apropiadamente" │
│ │
│ ✅ "El formulario tiene validación inline" │
│ ✅ "La página carga en menos de 2 segundos" │
│ ✅ "Email inválido muestra 'Ingresa un email válido'" │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ DETALLES DE IMPLEMENTACIÓN: │
│ ────────────────────────── │
│ ❌ "Usar React para el frontend" │
│ ❌ "Almacenar en base de datos PostgreSQL" │
│ ❌ "Usar REST API con JSON" │
│ │
│ ✅ "Los datos persisten después de refrescar la página" │
│ ✅ "La API responde en menos de 200ms" │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ DEMASIADOS: │
│ ─────────── │
│ ❌ 25 criterios de aceptación para una historia │
│ (la historia es muy grande, divídela) │
│ │
│ ✅ 3-8 criterios por historia es lo típico │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ MUY POCOS: │
│ ────────── │
│ ❌ Sin criterios ("ya lo resolveremos") │
│ ❌ Solo el camino feliz cubierto │
│ │
│ ✅ Cubrir camino feliz + casos de error clave │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ NO VERIFICABLE: │
│ ─────────────── │
│ ❌ "Los usuarios deben gustar el nuevo diseño" │
│ ❌ "El sistema debe ser escalable" │
│ │
│ ✅ "Encuesta de satisfacción puntúa 4/5+" │
│ ✅ "El sistema maneja 1000 solicitudes concurrentes" │
└─────────────────────────────────────────────────────────────┘