Criterios de Aceptación

Los criterios de aceptación definen las condiciones que deben cumplirse para que una historia de usuario se considere completa. Transforman requisitos vagos en especificaciones comprobables, eliminando ambigüedad y previniendo la expansión del alcance.

Propósito

Los criterios de aceptación sirven múltiples roles:

Para desarrolladores: Requisitos claros antes de comenzar a codificar Para testers: Condiciones exactas a verificar Para stakeholders: Definición transparente de entregables Para product owners: Aplicación del límite del alcance

Sin criterios de aceptación, "hecho" se vuelve subjetivo. Con ellos, la completación es binaria—todos los criterios pasan o el trabajo continúa.

Acceder al Editor

Abre los criterios de aceptación desde los detalles de la historia de usuario:

1. Navega a cualquier historia de usuario
2. Haz clic en la pestaña Detalles
3. Encuentra la sección Criterios de Aceptación
4. Haz clic en el botón Editar (ícono de lápiz)

El editor se abre en un modal con opciones de formato de texto enriquecido.

Características del Editor

Barra de Herramientas de Formato

El editor de criterios de aceptación soporta:

Soporte de Texto Enriquecido

El editor preserva el formato al pegar desde:

• Google Docs
• Confluence
• Notion
• Microsoft Word

Pega contenido formateado directamente—la estructura se transfiere automáticamente.

Escribir Criterios Efectivos

El Formato Given-When-Then

Esta estructura crea condiciones inequívocas y comprobables:

Dado [precondición]
Cuando [acción]
Entonces [resultado esperado]

Ejemplo:

Dado que estoy logueado como administrador
Cuando hago clic en "Eliminar Usuario" y confirmo el diálogo
Entonces el usuario es eliminado del sistema
Y veo una notificación de éxito
Y el usuario ya no aparece en la lista de usuarios

Formato de Lista de Verificación

Para validaciones más simples, usa checkboxes:

- [ ] El formulario valida formato de email
- [ ] La contraseña requiere 8+ caracteres
- [ ] El botón Enviar está deshabilitado hasta que el formulario sea válido
- [ ] Los mensajes de error se muestran debajo de campos inválidos
- [ ] El éxito redirige al dashboard

Especificación por Ejemplo

Muestra el comportamiento esperado exacto:

Entrada: "juan@ejemplo.com"
Esperado: Válido, proceder al siguiente paso

Entrada: "juan@"
Esperado: Error "Formato de email inválido"

Entrada: ""
Esperado: Error "El email es requerido"

Categorías de Criterios

Criterios Funcionales

Lo que la característica debe hacer:

Dado un usuario con ítems en el carrito
Cuando hace clic en "Checkout"
Entonces ve el formulario de pago
Y el total del carrito se muestra correctamente
Y las opciones de envío se calculan

Criterios No Funcionales

Cómo la característica debe comportarse:

Rendimiento:
- La página carga en menos de 2 segundos
- La búsqueda retorna resultados en menos de 500ms
- Soporta 100 usuarios concurrentes

Accesibilidad:
- Todos los campos del formulario tienen etiquetas
- La navegación con Tab funciona correctamente
- Compatible con lectores de pantalla

Casos Límite

Condiciones de frontera y estados de error:

Casos límite manejados:
- Búsqueda vacía retorna mensaje de ayuda
- Timeout de red muestra opción de reintentar
- Expiración de sesión redirige a login
- Datos inválidos muestran errores específicos

Criterios de Seguridad

Requisitos de protección:

Requisitos de seguridad:
- Contraseñas hasheadas antes de almacenar
- Sesión expira después de 30 min de inactividad
- Intentos de login fallidos limitados a 5
- Datos sensibles no se registran en logs

Anti-Patrones a Evitar

Muy Vago

❌ Malo:

- Debe funcionar correctamente
- Debe ser rápido
- Necesita manejar errores

✅ Bueno:

- Retorna status 200 con entrada válida
- Responde en menos de 500ms bajo carga normal
- Muestra "Error de red, por favor reintente" en timeout

Muy Técnico

❌ Malo (a menos que el equipo sea todo desarrolladores):

- Usa Redis pub/sub para actualizaciones en tiempo real
- Implementa bloqueo optimista con ETag
- Despliega via rolling update de Kubernetes

✅ Bueno:

- Los cambios aparecen para todos los usuarios en 3 segundos
- Ediciones simultáneas muestran advertencia de conflicto
- El despliegue causa cero tiempo de inactividad

Probando la Implementación

❌ Malo:

- Usa hooks de React correctamente
- Las consultas de base de datos están optimizadas
- El código sigue la guía de estilo

✅ Bueno:

- El componente se re-renderiza solo cuando los datos cambian
- La lista carga en menos de 1 segundo para 10,000 ítems
- Consistente con patrones de UI existentes

Expansión del Alcance

❌ Malo (añade trabajo no incluido en la historia):

- También añadir soporte de modo oscuro
- Incluir exportación a PDF
- Añadir atajos de teclado

✅ Bueno (mantener el alcance de la historia):

- El dashboard muestra todos los widgets
- Los widgets cargan la configuración guardada del usuario
- El layout persiste entre sesiones

Integración con el Flujo de Trabajo

Durante la Planificación

1. Creación de historia: Redactar criterios iniciales
2. Refinamiento: El equipo discute, añade casos límite
3. Estimación: Los criterios informan la asignación de story points
4. Planificación del sprint: Los criterios verifican que la historia está lista

Durante el Desarrollo

1. Referencia: El desarrollador revisa criterios mientras codifica
2. Auto-prueba: El desarrollador verifica cada criterio antes del PR
3. Revisión de código: El revisor verifica cobertura de criterios

Durante el Testing

1. Creación de casos de prueba: Cada criterio se convierte en caso de prueba
2. Verificación: El tester valida todos los criterios
3. Reportes de bugs: Referencia criterios específicos que fallaron

Durante la Demo

1. Recorrido: Muestra cada criterio siendo cumplido
2. Aprobación: El stakeholder confirma aceptación

Atajos de Teclado

En el editor de criterios de aceptación:

Mejores Prácticas

1. Escribe Criterios Antes del Desarrollo

Los criterios escritos después de codificar tienden a coincidir con la implementación en lugar de los requisitos. Escribe primero, codifica después.

2. Involucra al Equipo

Los desarrolladores detectan vacíos técnicos. Los testers encuentran casos límite. Incluye ambas perspectivas al escribir criterios.

3. Mantén los Criterios Atómicos

Cada criterio prueba una cosa:

❌ Combinado:

El usuario puede iniciar sesión con credenciales correctas y ve el dashboard con sus datos

✅ Atómico:

- Credenciales válidas otorgan acceso
- Credenciales inválidas muestran error
- El dashboard se muestra después del login
- El dashboard muestra solo los datos del usuario

4. Usa Lenguaje Consistente

Establece convenciones del equipo:

• "Usuario" vs "Cliente" vs "Miembro"
• "Clic" vs "Seleccionar" vs "Elegir"
• "Mostrar" vs "Visualizar" vs "Renderizar"

5. Incluye Casos Negativos

Lo que NO debe pasar también importa:

- La contraseña nunca se muestra en logs
- Los datos eliminados no pueden recuperarse
- La sesión expirada no puede acceder a rutas protegidas

6. Versiona los Criterios

Cuando los requisitos cambian, actualiza los criterios y nota por qué:

Actualizado 2024-01-15: Añadido requisito de 2FA por auditoría de seguridad
Anterior: Login requiere email + contraseña
Actual: Login requiere email + contraseña + código 2FA

Plantillas Comunes

Operaciones CRUD

Crear:
- Entrada válida crea registro
- Entrada inválida muestra errores específicos
- Prevención de duplicados funciona

Leer:
- Usuarios autorizados ven datos
- Usuarios no autorizados ven error
- Estado vacío muestra mensaje de ayuda

Actualizar:
- Cambios se guardan correctamente
- Validación aplica a actualizaciones
- Manejo de edición concurrente funciona

Eliminar:
- Confirmación requerida
- Soft delete preserva datos
- Hard delete elimina completamente

Validación de Formulario

Campo: Email
- Requerido (muestra error cuando está vacío)
- Validación de formato (usuario@dominio.com)
- Longitud máxima: 254 caracteres
- Verificación de unicidad (muestra error si existe)

Campo: Contraseña
- Requerido
- Mínimo 8 caracteres
- Al menos un número
- Al menos un carácter especial
- Indicador de fortaleza se muestra

Endpoint de API

Endpoint: GET /api/users/{id}

Éxito (200):
- Retorna objeto de usuario
- Excluye campos sensibles (contraseña, tokens)
- Tiempo de respuesta < 200ms

No Encontrado (404):
- Retorna formato de error estándar
- Mensaje: "Usuario no encontrado"

No Autorizado (401):
- Token faltante retorna error
- Token expirado retorna error
- Token inválido retorna error

Solución de Problemas

El formato no se guarda:

• Revisa la consola del navegador para errores
• Intenta limpiar caché del navegador
• Asegura conexión de red estable

El editor no abre:

• Verifica permiso edituserstories
• Comprueba que la historia no esté archivada
• Actualiza la página y reintenta

El contenido pegado pierde formato:

• Intenta Pegar y Coincidir Estilo (Cmd/Ctrl + Shift + V)
• Usa formato Markdown para contenido complejo
• Divide en operaciones de pegado más pequeñas

Los cambios no son visibles para el equipo:

• Verifica que el guardado se completó (modal cerrado)
• Busca errores de sincronización en el feed de actividad
• Los miembros del equipo pueden necesitar actualizar