System Design
Criterios de aceptación
Explica cómo convertir requisitos e historias en ejemplos verificables con condiciones, resultados, límites, errores y reglas de negocio observables.
- Última actualización
- Actualizada
- Nivel
- Fundamentos
System Design
Explica cómo convertir requisitos e historias en ejemplos verificables con condiciones, resultados, límites, errores y reglas de negocio observables.
Los criterios de aceptación convierten una necesidad en ejemplos observables. Su función no es repetir la historia, sino revelar cómo se comporta el sistema en condiciones concretas y permitir decidir si el resultado es aceptable.
Un criterio responde:
contexto conocido
+ acción o evento
→ resultado observablePuede expresarse con Given–When–Then, una tabla de ejemplos o afirmaciones verificables. El formato importa menos que la precisión.
Frases como “permitir cancelar pedidos” dejan preguntas:
Los criterios fuerzan a discutir estas condiciones antes de descubrirlas en pruebas o producción.
Describe el comportamiento o resultado que debe cumplirse para una historia o requisito.
Define datos, pasos, entorno y comprobaciones de una ejecución específica. Varios casos pueden derivarse de un criterio.
Reúne condiciones generales del equipo: revisión, pruebas, documentación, seguridad y despliegue.
No mezcles “el pedido queda cancelado” con “el PR fue aprobado”.
Dado [estado y contexto relevante]
cuando [acción o evento]
entonces [resultado observable]Ejemplo:
Dado un pedido confirmed que aún no está en preparación,
cuando el cliente solicita cancelarlo,
entonces el pedido queda cancelled,
la reserva de inventario se libera una vez
y se registra el motivo.Given no debe describir todos los detalles internos. Incluye solo lo necesario para entender el escenario.
Confirma el flujo permitido.
Muestra una regla que rechaza la operación.
Dado un pedido delivered,
cuando se solicita cancelación,
entonces la operación se rechaza
y el estado permanece sin cambios.Prueba límites exactos:
Dado stock vendible de 5,
cuando se solicitan 5 unidades,
entonces la reserva se acepta.
Dado stock vendible de 5,
cuando se solicitan 6,
entonces se rechaza sin cambios parciales.Las fronteras descubren errores de comparación mejor que ejemplos medios.
regla abstracta
→ ejemplos representativos
→ conversación
→ modelo compartido
→ pruebas automatizadas o manualesLos ejemplos no cubren todas las combinaciones, pero ayudan a encontrar la regla general. Evita convertir cada dato posible en criterio.
¿Qué cambio observable justifica la entrega?
¿Qué condiciones cambian el resultado?
Happy path, límite, permiso, error y repetición cuando sean relevantes.
Datos persistidos, estados, eventos, auditoría y ausencia de cambios parciales.
Usa términos del dominio y evita detalles de implementación.
Debe existir una observación o medición que permita decidir.
CA-01 Entrada válida
Dado un producto activo en la sucursal
cuando el encargado registra 20 unidades con motivo “compra”
entonces se crea un movimiento de entrada por 20,
el stock aumenta en 20
y se registra actor y timestamp.
CA-02 Cantidad inválida
Dado un producto activo
cuando se intenta registrar cantidad 0 o negativa
entonces se rechaza sin crear movimiento ni alterar stock.
CA-03 Repetición
Dado que una entrada con referencia externa PO-100 ya fue procesada
cuando se reenvía la misma referencia
entonces se devuelve el resultado existente y no se duplica el movimiento.
CA-04 Concurrencia
Dado dos entradas diferentes sobre el mismo producto
cuando se procesan simultáneamente
entonces ambas quedan registradas y el stock final refleja la suma exacta.Estos criterios abarcan validez, atomicidad, idempotencia y concurrencia sin especificar base de datos o framework.
Cuando varias condiciones cambian el resultado, una tabla reduce repetición.
| Estado | Actor | Pago | Resultado |
|---|---|---|---|
| pending | cliente | no cobrado | cancelar |
| confirmed | cliente | cobrado | solicitar revisión |
| confirmed | manager | cobrado | cancelar y reembolsar |
| delivered | cualquiera | cobrado | iniciar devolución |
La tabla ayuda a detectar combinaciones sin definición.
Un buen criterio es:
También pueden expresar cualidades:
Dado tráfico de 200 solicitudes por segundo durante 30 minutos,
cuando se crean pedidos con el dataset representativo,
entonces p95 permanece por debajo de 700 ms
y los errores técnicos por debajo de 0.2 %.La medición debe indicar entorno, carga y duración.
Evita solo “usuario no autorizado no puede acceder”. Define alcance y efecto:
Dado un manager de la sucursal A,
cuando consulta un pedido exclusivo de la sucursal B,
entonces no recibe sus datos
y el intento se registra según la política de auditoría.El código de respuesta puede depender del contrato; el criterio protege el resultado de seguridad.
Ejemplo:
Dado que la pasarela no responde dentro del timeout,
cuando se intenta confirmar el pago,
entonces el pedido queda payment_pending,
no se registra como pagado
y puede reconciliarse sin duplicar cobro.No todo fallo debe producir rollback total; el criterio define el estado seguro.
Son fáciles de omitir porque no aparecen en una demo manual. Inclúyelas cuando el dominio puede recibir solicitudes simultáneas o reintentos.
Preguntas:
Define empty state o resultado cero, no error genérico.
La operación debe validar estado actual y responder coherentemente.
Decide ignorar, aplicar, guardar pendiente o reconciliar.
El reintento debe ser seguro.
Aclara zona horaria e inclusión del instante exacto.
Considera límites de cantidad, longitud, archivo o batch.
Define migración o rechazo, no comportamiento accidental.
“Dado que quiero cancelar, cuando cancelo, entonces se cancela” no añade información.
“Crear endpoint y tabla” no confirma valor.
Deja reglas y recuperación sin acuerdo.
Hace frágil el criterio ante rediseños. Incluye interfaz solo cuando forma parte del contrato de accesibilidad o experiencia.
Una historia con veinte reglas distintas quizá necesita dividirse o convertirse en caso de uso.
No todo criterio debe convertirse en test end-to-end textual. Selecciona el nivel de prueba adecuado.
criterio de negocio
→ pruebas unitarias de reglas
→ integración de persistencia/contratos
→ end-to-end de flujo crítico
→ observabilidad en producciónNo dupliques cada escenario en todos los niveles. Protege la lógica donde falla de forma más clara y agrega pocos recorridos end-to-end.
Los criterios funcionan mejor con Example Mapping:
historia
→ reglas
→ ejemplos
→ preguntasNegocio aporta significado, testing busca fronteras y desarrollo identifica implicaciones. La conversación reduce retrabajo antes del código.
No existe número fijo. Son suficientes cuando cubren el resultado, las reglas que cambian comportamiento, los fallos relevantes y permiten al equipo implementar y verificar sin suposiciones críticas ocultas.
Casos de uso desarrolla objetivos completos con actores, garantías, flujos alternativos y excepciones.