# Especificación de casos de prueba

Convierte unos criterios acordados en casos que alguien puede ejecutar — cada uno con sus datos, su resultado esperado y el criterio que existe para cubrir.

## Entregable

Un documento Markdown, `test-cases.md`, con la estructura fijada en **Salida** más abajo. Toma la salida de **Redacción de criterios de aceptación** y se convierte en el material que la **Auditoría de la suite de regresión** juzga más adelante.

## Entradas obligatorias

- **Los criterios o la especificación a cubrir** — las secciones 3 a 6 de `acceptance-criteria.md` son la forma esperada; vale cualquier enunciado escrito de comportamiento acordado.
- **El nivel para el que se escriben los casos** — el de la estrategia de pruebas cuando existe. Un caso sin nivel no se puede colocar, ni automatizar, ni asignar.

Sin ambas, detente. Nunca escribas casos desde la implementación: un caso derivado del código afirma lo que el código hace, y sigue pasando tanto si eso es correcto como si no.

## Entradas opcionales

- Los datos de prueba disponibles: qué existe, cómo se crean, qué está restringido
- El entorno en el que se ejecutarán los casos y en qué se diferencia de producción
- Los casos existentes que cubren la misma área
- Los defectos conocidos del área y las condiciones que los provocaron
- Las interfaces sometidas a prueba: pantallas, endpoints, trabajos programados, mensajes
- Quién ejecutará los casos y si a mano o a través del ejecutor de pruebas

Que falte una entrada opcional no detiene la especificación. Cada caso registra los datos que necesita; cuando no se conoce su origen, el caso se marca `origen de datos desconocido` y se lista en **Información que falta**, en lugar de escribirse contra datos que alguien supone que existen.

## Ejecución

**1 — Tomar los criterios de uno en uno.** Cada criterio recibe al menos un caso. Un criterio que no se pueda convertir en caso se devuelve como no comprobable tal como está escrito, con lo que lo impide — nunca se aproxima con un caso que prueba algo parecido.

**2 — Dividir las entradas en clases.** Agrupa los valores que el comportamiento trata igual, escribe un caso por clase y añade después un caso en cada borde de la clase y en el primer valor fuera de ella. El objetivo es un conjunto pequeño cuya cobertura se pueda argumentar, no uno grande cuya cobertura se confía.

**3 — Enunciar las precondiciones.** Por caso: la cuenta y sus permisos, el estado de los datos y el estado de cada sistema del que el caso depende. Una precondición que nadie puede crear es un bloqueo, y se registra como tal en lugar de dejarla para que la descubra quien ejecute el caso.

**4 — Nombrar los datos.** Por caso: qué datos necesita, de dónde vienen — un fixture, generados, precargados o pedidos a quien los posee — y si otro caso puede reutilizarlos. Los datos que todavía no existen se nombran como necesarios, nunca se inventan dentro del caso.

**5 — Escribir los pasos y el resultado esperado.** Una acción por paso, en el orden en que se hacen. El resultado esperado se enuncia con precisión suficiente para poder fallar: el estado, registro, mensaje o respuesta que debe observarse. Un resultado que dice que el comportamiento funciona como se espera no puede fallar y, por tanto, tampoco puede pasar.

**6 — Escribir la limpieza.** Qué crea el caso, qué debe eliminar o restablecer y qué puede dejar atrás. Un caso que deja estado convierte su propio desorden en el fallo del siguiente, y el siguiente es el que se investiga.

**7 — Trazar en ambos sentidos.** Cada caso nombra el criterio que cubre; cada criterio nombra los casos que lo cubren. Los criterios sin caso son huecos de cobertura. Los casos sin criterio son o un criterio que falta o un caso que nadie necesita — se reportan los dos y aquí no se borra ninguno.

## Salida

`test-cases.md`, en este orden:

- **1. Entrada y fecha** — qué criterios se cubren, el nivel para el que se escriben los casos, quién los escribió y cuándo
- **2. Casos** — por caso: identificador, título, nivel, precondiciones, datos, pasos, resultado esperado, limpieza y el criterio cubierto
- **3. Análisis de cobertura** — por criterio: las clases y los límites identificados y los casos que cubren cada uno
- **4. Criterios sin caso** — el criterio, qué impide escribir un caso y qué hace falta para escribirlo
- **5. Casos sin criterio** — el caso, qué afirma y la decisión que debe tomar quien acepta
- **6. Requisitos de datos** — por conjunto de datos: qué es, de dónde viene, si está restringido y quién lo posee
- **7. Casos bloqueados** — casos que no se pueden ejecutar, la precondición o el acceso que necesitan y quién puede aportarlo
- **8. Información que falta** — qué impidió especificar un caso y quién puede desbloquearlo

## Validación

El conjunto está listo cuando se cumple todo esto:

- Cada criterio de la entrada aparece en la sección 2 o en la sección 4
- Cada caso nombra sus precondiciones, su origen de datos y su limpieza, o declara que no necesita ninguno
- Cada resultado esperado nombra algo observable y fallaría si el comportamiento cambiara
- Cada caso nombra el criterio que cubre, o aparece en la sección 5
- No aparece en ningún caso un valor, límite o formato que la entrada no aportara
- Las secciones 4 y 5 están presentes aunque estén vacías, y lo declaran cuando lo están

Falla la ejecución si un resultado esperado no se puede observar, o si un caso depende de datos que ninguna entrada aportó.

## Gestión de fallos

- **No hay criterios** — detente. Informa de que los casos no se pueden especificar desde una implementación y nombra qué hace falta primero.
- **Un criterio no es comprobable tal como está escrito** — no lo aproximes. Regístralo en la sección 4 con lo que lo impide y devuélvelo a quien lo redactó.
- **Sin entorno o sin datos de prueba** — especifica los casos por completo, márcalos como `NO EJECUTADO` y lista en la sección 7 el acceso que hace falta. Un caso especificado que no se ha ejecutado es honesto; un caso registrado como superado sin ejecutarse es peor que ningún caso.
- **Criterios contradictorios** — no escribas ningún caso para la contradicción. Registra ambas lecturas en la sección 8 como bloqueantes, nombra ambas fuentes y deja la elección a quien acepta.
- **Material parcial** — especifica lo que el material sostenga, marca el resto como `INCOMPLETO — pendiente de <pregunta>` y reporta la cobertura que el conjunto tiene de verdad, no la que aparenta.