# Definición de estrategia de pruebas

Decide cómo se probará un cambio antes de que nadie escriba una prueba — qué riesgos se cubren en qué nivel, qué queda deliberadamente sin automatizar y quién responde de cada parte.

## Entregable

Un documento Markdown, `test-strategy.md`, con la estructura fijada en **Salida** más abajo. Fija los niveles para los que **Especificación de casos de prueba** escribe casos, y el marco contra el que la **Auditoría de la suite de regresión** juzga una suite existente.

## Entradas obligatorias

- **Qué se está construyendo o cambiando** — el sistema, servicio o cambio sometido a prueba, en la forma escrita que exista.
- **El riesgo que carga** — qué cuesta cuando esto falla: a quién afecta, qué se rompe y si el daño es recuperable.
- **Quién responde de la calidad de este trabajo**, al menos por rol. Alguien tiene que poder decir que la estrategia está equivocada.

Si falta cualquiera de las tres, detente y repórtalo. Una estrategia escrita sin un riesgo declarado acaba cubriendo lo que resulta más fácil de alcanzar.

## Entradas opcionales

- La arquitectura: componentes, integraciones, servicios externos, almacenes de datos
- Los entornos disponibles y en qué se diferencia cada uno de producción
- Datos de prueba: qué existe, cómo se crean y qué está restringido
- La cadena de publicación por la que pasa este trabajo y qué bloquea hoy
- Las pruebas automatizadas existentes y su historial de ejecuciones
- Objetivos de cobertura, obligaciones regulatorias o compromisos contractuales, cada uno con la persona o el documento que lo declara

Las entradas opcionales que falten pasan a **Preguntas abiertas**. Los objetivos de cobertura solo se registran cuando quien lo pide declara uno; esta habilidad nunca fija una cifra por su cuenta, y una categoría sin objetivo declarado se escribe `sin objetivo aportado`.

## Ejecución

**1 — Listar los riesgos, no las funcionalidades.** Por cada riesgo: qué falla, a quién afecta, qué cuesta y si es recuperable. Un riesgo del que nadie sabe nombrar una consecuencia no es un riesgo — quítalo de la lista en lugar de probar contra él.

**2 — Asignar cada riesgo a un nivel.** Coloca cada riesgo en el nivel más barato que de verdad pueda detectarlo: cuanto más cerca del código, más rápida la respuesta y más estrecha la evidencia. Registra el nivel junto al riesgo. Un riesgo que no cubre ningún nivel se escribe como no cubierto, no se traslada en silencio a un nivel que no puede verlo.

**3 — Decidir qué queda deliberadamente sin automatizar.** Nombra las comprobaciones que siguen siendo manuales o exploratorias y el motivo de cada una: cambia demasiado a menudo para codificarla, exige un juicio que ninguna aserción puede hacer, cuesta más automatizarla de lo que vale el riesgo. Un hueco sin documentar se convierte más tarde en un accidente; uno documentado es una decisión.

**4 — Nombrar el entorno y los datos que necesita cada nivel.** Por nivel: dónde se ejecuta, qué datos necesita, de dónde salen esos datos y qué está restringido. Donde el entorno se diferencie de producción, registra la diferencia y la clase de defecto que esa diferencia oculta.

**5 — Dar un dueño a cada nivel.** Por nivel: quién escribe las pruebas, quién las ejecuta y quién las arregla cuando fallan. Un nivel sin dueño con nombre deja de mantenerse, y nadie se da cuenta hasta que hace falta.

**6 — Definir qué bloquea la cadena de publicación.** Qué niveles frenan un cambio y cuáles solo informan, qué pasa con un cambio frenado, quién puede saltarse una puerta y dónde queda registrado ese salto. Una puerta que nadie puede saltarse se esquiva por otro sitio; un salto que nadie registra no es una puerta.

**7 — Fijar la regla de intermitencia antes de que haya intermitencia.** Cómo se detecta un fallo intermitente, a quién se avisa, si se pone en cuarentena, quién lo arregla y el plazo que el equipo acuerda para ese arreglo. Escribe el plazo que declara el equipo, nunca uno elegido aquí. Una suite sin esta regla enseña a la gente a ignorar los fallos.

## Salida

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

- **1. Alcance y fecha** — qué se somete a prueba, qué queda excluido, quién escribió la estrategia y cuándo
- **2. Riesgos** — una línea cada uno: qué falla, a quién afecta, qué cuesta, recuperable o no
- **3. Niveles** — por nivel: los riesgos que cubre, lo que explícitamente no cubre y por qué se eligió ese nivel
- **4. Sin automatizar** — qué sigue siendo manual o exploratorio, con el motivo registrado en cada entrada
- **5. Entornos y datos** — por nivel: entorno, datos, de dónde salen los datos y en qué se diferencia el entorno de producción
- **6. Propiedad** — por nivel: quién escribe, quién ejecuta, quién arregla
- **7. Puertas de la cadena** — qué niveles bloquean, cuáles informan, qué le pasa después a un cambio frenado, quién puede saltarlas y dónde queda registrado
- **8. Regla de intermitencia** — detección, aviso, cuarentena, responsable y el plazo de arreglo tal como lo declara el equipo
- **9. Objetivos de cobertura** — solo los que declaró quien lo pide, cada uno con la persona o el documento que lo fijó; si no, `sin objetivo aportado`
- **10. Preguntas abiertas** — qué no se pudo decidir, qué bloquea y quién lo decide

## Validación

La estrategia está lista cuando se cumple todo esto:

- Cada riesgo de la sección 2 aparece en la sección 3 o en la 4, o figura como no cubierto
- Cada entrada de la sección 4 lleva un motivo
- Cada nivel de la sección 3 tiene un dueño con nombre en la sección 6
- La sección 7 declara, para cada nivel, si bloquea o solo informa
- La sección 9 no lleva ninguna cifra que quien lo pide no haya declarado
- La sección 10 no está vacía, o declara explícitamente que no queda nada pendiente

Falla la ejecución si ningún nivel cubre un riesgo y este no queda registrado como no cubierto, o si una cifra de cobertura aparece sin la persona que la fijó.

## Gestión de fallos

- **No hay riesgo declarado** — detente. Informa de que la estrategia no tiene nada contra lo que elegir un nivel y nombra a quien debe declarar el riesgo.
- **Sin acceso a los entornos ni a la cadena de publicación** — escribe las secciones 5 y 7 a partir de lo reportado, márcalas como `reportado` de principio a fin y declara que no se verificó nada y que cada puerta descrita puede diferir de la que se ejecuta.
- **Instrucciones contradictorias sobre qué debe automatizarse** — registra ambas, nombra ambas fuentes y eleva la contradicción a la sección 10 como bloqueante. No la zanjes eligiendo la más estricta.
- **Se exige un objetivo de cobertura pero nadie lo declara** — escribe `sin objetivo aportado` en la sección 9 y nombra a quien debe fijarlo. Nunca aportes una cifra para cerrar la sección.
- **Material parcial** — produce cada sección que el material sostenga, marca el resto como `INCOMPLETO — pendiente de <pregunta>` y entrega. Una estrategia que nombra sus huecos se puede revisar; una que los rellenó, no.