# Auditoría de la suite de regresión Informa de lo que vale de verdad una suite automatizada existente — qué pruebas protegen algo, cuáles enseñan a ignorar los fallos y cuáles habría que borrar. ## Entregable Un documento Markdown, `regression-suite-audit.md`, con la estructura fijada en **Salida** más abajo. Lee la suite contra los niveles que fija **Definición de estrategia de pruebas**, y sus hallazgos alimentan la siguiente revisión de esa estrategia. ## Entradas obligatorias - **La suite automatizada** — el código de las pruebas, o un listado con detalle suficiente para ver qué afirma cada prueba y en qué nivel se ejecuta. - **Qué debe proteger la suite** — el comportamiento cuya rotura existe para detectar. - **Quién es dueño de la suite**, al menos por rol — quien puede actuar sobre una recomendación de borrar una prueba. Si falta cualquiera de las tres, detente y repórtalo. El historial de ejecuciones no es obligatorio, pero su ausencia cambia lo que esta auditoría puede concluir. ## Entradas opcionales - Historial de ejecuciones: pasa, falla y omitida por prueba, durante el periodo que indique quien lo pide - Los defectos que llegaron a producción desde que la suite existe - Tiempo de ejecución medido, por prueba y del conjunto - El registro de mantenimiento: qué pruebas se editaron y si la edición siguió a un cambio de comportamiento o a una refactorización - La propiedad por prueba o por área - La estrategia de pruebas contra la que se construyó la suite Sin historial de ejecuciones la auditoría solo reporta hallazgos estructurales — qué afirma una prueba, qué duplica, a qué está acoplada — y declara en su primera línea que no fue posible ningún juicio de comportamiento. Ninguna prueba se llama intermitente, ni prueba que nunca falla, sin el historial que lo demuestre. ## Ejecución **1 — Inventariar la suite.** Una línea por prueba: nombre, nivel, qué afirma, el área que cubre y su dueño cuando se conoce. Una prueba cuya afirmación no cabe en una línea se registra como `afirmación poco clara` y sigue adelante así — es la primera candidata a reescritura, porque tampoco nadie puede actuar sobre su fallo. **2 — Clasificar cada prueba contra su historial.** Nunca ha fallado, falla ante regresiones reales, falla de forma intermitente, falla ante cambios sin relación con lo que afirma, omitida o desactivada. Cada clasificación cita el historial que la sostiene. Una prueba sin historial se registra como `sin historial` y no recibe ninguna clasificación de comportamiento. **3 — Separar comportamiento de implementación.** Por cada prueba, decide si afirma algo de lo que depende una persona usuaria o un sistema llamante, o algo interno: orden de llamadas, estructura privada, marcado exacto, la forma de un valor intermedio. Registra cada afirmación de implementación junto a la refactorización que la rompería con el comportamiento intacto. **4 — Poner precio a las intermitentes.** Lista cada prueba que falla de forma intermitente con la respuesta que el equipo le da hoy: relanzar, ignorar, investigar. Donde la respuesta sea relanzar o ignorar, declara con claridad que en esa área la suite ha dejado de ser una señal, y que un fallo real allí recibiría el mismo trato. **5 — Poner precio a la suite.** Tiempo de ejecución por prueba y total, solo a partir de las mediciones aportadas; el mantenimiento que muestra el registro; y en qué punto de la cadena cae el coste. Un tiempo que nadie midió es `desconocido`, y un total construido sobre desconocidos se reporta como desconocido en lugar de sumarse. **6 — Comprobar qué se escapó.** Por cada defecto de producción aportado, decide si una prueba podría haberlo detectado, en qué nivel y qué hueco lo dejó pasar. Los huecos por los que algo se ha roto de verdad son los que importan; los huecos de áreas que nunca se han roto se listan aparte y por debajo. **7 — Recomendar por prueba.** `conservar`, `arreglar`, `reescribir` o `borrar`, cada una con la evidencia que la sostiene y el coste de actuar. Un `borrar` nombra qué deja de estar protegido y quién debe aceptarlo. Una recomendación sin evidencia es una opinión sobre el código de otra persona. ## Salida `regression-suite-audit.md`, en este orden: - **1. Entrada y fecha** — qué suite se auditó, qué historial se aportó y de qué periodo, quién la auditó y cuándo - **2. Registro** — una línea por prueba: nombre, nivel, qué afirma, clasificación, recomendación y la evidencia citada - **3. Pruebas que nunca fallan** — por prueba: qué afirma y si guarda algo estable o no afirma nada - **4. Pruebas intermitentes** — por prueba: el patrón que muestra el historial y la respuesta que el equipo le da hoy - **5. Pruebas acopladas a la implementación** — por prueba: el detalle interno que afirma y la refactorización que la rompería - **6. Coste** — tiempo medido por prueba y total, mantenimiento observado y dónde cae el coste; `desconocido` donde no se midió nada - **7. Defectos escapados** — por defecto: qué no vio la suite, en qué nivel se podría haber detectado y el hueco responsable - **8. Huecos de cobertura** — los huecos por los que algo se ha roto, y después aquellos por los que nada se ha roto, separados - **9. Recomendaciones** — por prueba: `conservar`, `arreglar`, `reescribir` o `borrar`, la evidencia, el coste de actuar y qué deja de proteger un `borrar` - **10. Información que falta** — qué no se pudo juzgar y quién puede aportar lo que hace falta ## Validación La auditoría está lista cuando se cumple todo esto: - Cada prueba de la suite aportada aparece exactamente una vez en la sección 2 - Cada clasificación de la sección 2 cita el historial en el que se apoya, o dice `sin historial` - Cada recomendación nombra su evidencia, y cada `borrar` nombra qué deja de estar protegido - Ninguna prueba se describe como intermitente ni como prueba que nunca falla sin el historial que lo muestre - La sección 6 lleva solo cifras medidas; lo que no se midió dice `desconocido` - La sección 1 declara si se aportó historial y qué no pudo concluir la auditoría por ello Falla la ejecución si aparece un juicio sin la evidencia detrás, o si aparece un tiempo de ejecución que nadie midió. ## Gestión de fallos - **Sin historial de ejecuciones** — produce las secciones 1, 2, 5, 9 y 10 solo desde el código, marca las secciones 3, 4 y 6 como `sin historial aportado` y declara en la primera línea que la auditoría es estructural y que ninguna prueba se juzgó por cómo se comporta. - **Sin acceso al código de las pruebas** — audita desde el listado aportado, marca cada hallazgo como `reportado` y declara que no se leyó nada. Una suite juzgada por sus nombres se juzga por lo que alguien esperaba que hiciera cada prueba. - **La suite y el historial no cuadran** — cuando el historial nombra pruebas que ya no existen, o hay pruebas sin historial alguno, registra ambas cosas, nombra ambas fuentes y elévalo a la sección 10. No lo reconcilies descartando un lado. - **Una prueba sin dueño** — regístrala como `dueño desconocido` en la sección 2 y lístala en la sección 10. Una prueba sin dueño que falla es la que se relanza hasta que pasa. - **Material parcial** — audita lo aportado, marca el resto como `INCOMPLETO — pendiente de ` y nombra la parte de la suite que no se examinó. Una auditoría que cubre media suite y lo dice es utilizable; una que da a entender que las cubrió todas, no.