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 <pregunta> 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.
