La deuda de pruebas heredadas no se tolera por indisciplina. Se tolera porque pagarla a mano consume años-ingeniero que ninguna hoja de ruta aprobará jamás.
Toda organización de verificación madura tiene el mismo activo: una suite construida durante una década por gente que en su mayoría ya se fue, en formatos que cambiaron tres veces, con convenciones que nunca se escribieron. Funciona, casi siempre. Nadie quiere tocarla.
Del estándar
“Verification and validation (V&V) processes are used to determine whether the development products of a given activity conform to the requirements of that activity and whether the product satisfies its intended use and user needs.”
En qué consiste realmente la deuda
Las verificaciones suelen estar bien. Alguien entendió el comportamiento y lo comprobó, y ese criterio sigue siendo válido. Lo que falta es todo lo que rodea a la verificación.
La estructura varía. Los casos escritos en distintas épocas usan convenciones de campo diferentes, así que las herramientas no pueden analizarlos de forma uniforme ni los revisores escanearlos rápido.
Las precondiciones son implícitas. El autor original sabía en qué estado debía estar el sistema. No lo registró, porque le resultaba obvio. Hoy no lo es para nadie, y es la causa más común de que un caso falle por razones ajenas al comportamiento que prueba.
Los elementos de interfaz se nombran en prosa. Un paso dice "poner la entrada de presión en alto" en lugar de nombrar el elemento, así que ninguna herramienta puede determinar qué ejercita el caso y no puede participar en el análisis de cobertura.
No hay trazabilidad. No hay requisito adjunto, así que nadie puede decir si el caso sigue justificado o si el comportamiento que protege se retiró hace dos entregas.
Por qué nunca se agenda
Cuatro mil casos a treinta minutos cada uno son aproximadamente un año-ingeniero. El beneficio es enteramente preventivo y se manifiesta como cosas que no ocurren, así que compite contra trabajo de producto con un caso de ingresos cuantificado y pierde en cada ciclo de planificación. Ese resultado es racional dadas las entradas — por eso la solución debe cambiar las entradas.
Adaptar en lugar de reescribir
El instinto es regenerar la suite desde los requisitos y descartar los casos antiguos. Esto suele ser un error, y caro.
Esos casos codifican una década de conocimiento acumulado sobre cómo falla realmente el sistema — condiciones límite descubiertas en campo, secuencias que solo fallan en una revisión de hardware específica, sensibilidades temporales para las que nadie escribió un requisito. Regenerar desde los requisitos produce una suite limpia que ha olvidado cada lección que la organización pagó por aprender.
Adaptar conserva la verificación y reconstruye la estructura a su alrededor: normalizar el formato, explicitar las precondiciones, resolver las referencias en prosa a elementos de interfaz reales y adjuntar el requisito que justifica el caso. El criterio de ingeniería sobrevive; el andamiaje se reemplaza.
El diff es todo el mecanismo de seguridad
La modernización automatizada toca miles de casos que hoy funcionan. El modo de falla no es dramático — es una verificación sutilmente debilitada que nadie nota hasta que el defecto que solía detectar llega a un cliente.
Por eso la ruta de escritura debe mostrar un diff por campo contra el caso existente, con pasos editables antes de aprobar. Un revisor necesita ver exactamente qué cambia en cada campo — no un resumen, y nunca un reemplazo total presentado como actualización.
Revisar un diff es rápido de una forma en que crear no lo es. Esa asimetría es lo que hace funcionar la economía: la parte cara nunca fue el criterio, fue la transcripción.
Secuencie el trabajo por riesgo
No empiece por el caso uno. Empiece por las suites que cubren comportamiento que cambió recientemente, luego las ligadas a requisitos con mayor nivel de integridad, y después las que un escaneo de cobertura señale como lo único que verifica un elemento dado.
Ese orden adelanta el valor, y significa que el esfuerzo puede detenerse en cualquier punto habiendo ya retirado la deuda más riesgosa. Un programa de modernización que debe completarse para entregar algo es un programa que se cancelará al 40 por ciento.
Retire casos además de repararlos
Adjuntar requisitos a los casos heredados revela los huérfanos — casos que verifican comportamiento sin justificación porque el requisito se retiró. Esos deben eliminarse, no modernizarse. Los equipos encuentran consistentemente que esta categoría es mayor de lo esperado, y borrarla es la mejora de cobertura más barata disponible.
Axionalytics
IA agéntica en producción para equipos empresariales de ingeniería, datos e ingresos.