# Redacción de criterios de aceptación Convierte un requisito en criterios que se pueden comprobar sin discusión — incluidos los estados que un requisito suele olvidar. ## Entregable Un documento Markdown, `acceptance-criteria.md`, con la estructura fijada en **Salida** más abajo. Es la entrada de **Especificación de casos de prueba**. ## Entradas obligatorias - **El requisito, tal como está escrito** — una historia, un ticket, un párrafo de especificación o una petición por escrito, en palabras de quien lo redactó. - **Una persona aceptadora con nombre** — quien decide si un criterio se cumple. Sin ella, los criterios son sugerencias. Si falta cualquiera de las dos, detente y repórtalo. Nunca deduzcas los criterios de la implementación: el código dice qué ocurre, no qué se acordó. ## Entradas opcionales - El comportamiento existente junto al que se coloca el cambio - Los roles y permisos que le aplican - Reglas de datos: campos obligatorios, formatos, límites, retención - Diseños de interfaz, los textos o un recorrido del flujo - Obligaciones regulatorias, contractuales o de accesibilidad - Defectos abiertos antes en la misma área Cada entrada opcional que falte estrecha lo que se puede afirmar, y cada hueco pasa a **Preguntas**. Una regla que falta nunca se sustituye por un valor por defecto razonable; ese valor se aprueba en revisión y se discute tras el lanzamiento. ## Ejecución **1 — Reenunciar el requisito en una frase.** Quién, qué puede hacer y qué es distinto después. Si no cabe en una frase, lleva más de un requisito dentro: divídelo y redacta los criterios de cada parte por separado. **2 — Listar las palabras que no se pueden comprobar.** Términos como `rápido`, `válido`, `adecuado`, `según convenga`, y cualquier lista que acabe en `etc.`, no tienen significado observable. Cada uno se convierte en una pregunta que nombra a quien puede zanjarlo. Ninguno se zanja aquí eligiendo la lectura más probable. **3 — Redactar el camino de éxito.** Un criterio por comportamiento, en forma dado / cuando / entonces. El `entonces` enuncia algo que una persona o un sistema llamante puede observar: una pantalla, un registro, una respuesta, un mensaje. Un `entonces` que dice que el sistema lo gestiona no afirma nada. **4 — Redactar los límites.** La entrada aceptada más pequeña y la más grande, el primer valor rechazado a cada lado, la entrada vacía, la longitud máxima y los límites de cada campo. Cada límite se expresa como la regla que lo gobierna y cita la entrada que aportó esa regla; donde ninguna entrada aportó un límite, el límite se convierte en pregunta y no en cifra. **5 — Redactar los caminos de error.** Por cada forma de fallar: qué ve la persona usuaria, qué registra el sistema y en qué estado quedan los datos. Un requisito que solo describe el éxito no está especificado, está imaginado. **6 — Redactar los estados que el requisito olvidó.** Sin permiso. Sin autenticar. Todavía sin datos. Datos parciales. Un cambio simultáneo de otra persona. Un flujo interrumpido que se retoma más tarde. Cada uno es un criterio o una línea explícita de fuera de alcance que nombra a quien lo decidió. **7 — Comprobar cada criterio por separado.** Un criterio afirma una sola cosa, se puede comprobar sin ejecutar otro antes y no necesita leer la implementación para entenderse. Fusiona los criterios que solo significan algo juntos; divide los que afirman dos cosas; reescribe cualquiera cuya verdad dependa de cómo se construyó. ## Salida `acceptance-criteria.md`, en este orden: - **1. Requisito y fuente** — el requisito literal, de dónde viene, quién lo acepta y la fecha - **2. Reenunciado** — la frase única contra la que se escribieron los criterios, y la división si la hubo - **3. Criterios de éxito** — numerados, cada uno en forma dado / cuando / entonces - **4. Criterios de límite** — por límite: la regla, el primer valor fuera de ella y la entrada que aportó la regla - **5. Criterios de error** — por fallo: qué ve la persona usuaria, qué se registra, en qué estado quedan los datos - **6. Criterios de estado** — permiso, autenticación, sin datos, datos parciales, concurrencia, interrupción: cada uno cubierto o explícitamente fuera de alcance - **7. Fuera de alcance** — qué no cubre este requisito deliberadamente y quién lo decidió - **8. Preguntas** — cada palabra no comprobable y cada regla que ninguna entrada aportó, con lo que bloquea y quién puede zanjarla ## Validación El conjunto está listo cuando se cumple todo esto: - Cada criterio está en forma dado / cuando / entonces y nombra un resultado observable - Cada criterio se puede comprobar por sí solo, sin ejecutar antes otro criterio - Las secciones 4, 5 y 6 no están vacías, o declaran que el requisito no tiene ese caso y quién lo confirmó - No aparece ningún límite, formato ni umbral que no haya aportado una entrada - Cada palabra no comprobable hallada en la sección 1 aparece en la sección 8 o ha sido sustituida por una regla - La sección 8 no está vacía, o declara explícitamente que no queda nada pendiente Falla la ejecución si un criterio todavía contiene una palabra listada en la sección 8, o si aparece un valor que ninguna entrada aportó. ## Gestión de fallos - **No hay requisito** — detente. Informa de que los criterios no se pueden escribir desde una implementación y nombra qué hace falta. - **No hay persona aceptadora** — produce las ocho secciones y marca la sección 1 como `SIN ACEPTAR`. Unos criterios en ese estado no sirven para dar el trabajo por bueno. - **El requisito se contradice a sí mismo o a una regla aportada** — no escribas criterios para ninguna de las dos lecturas. Registra ambas, nombra ambas fuentes y eleva la contradicción a la sección 8 como bloqueante. - **Sin acceso al comportamiento existente** — redacta los criterios solo del cambio y declara en la sección 8 que su interacción con lo que ya existe no se examinó y sigue sin especificar. - **Material parcial** — redacta cada criterio que el material sostenga, marca el resto como `INCOMPLETO — pendiente de ` y entrega. Un conjunto con huecos nombrados se puede revisar; uno que los rellenó se aprueba y luego se discute.