Deuda técnica y pruebas de regresión
En sistemas donde la deuda técnica es alta la definición y ejecución de pruebas de regresión resulta esencial. Cuando la situación del código y la arquitectura es tan mala no es suficiente con tener la sensación de que se tiene controlado todo lo que se modifica sino que además es necesario verificar que el sistema sigue funcionando de manera adecuada, incluso en aquellas partes del mismo donde se piensa que es imposible que tengan efecto los cambios realizados.
Sin pruebas de regresión estamos prácticamente jugando a los dados en cada paso a producción y un sistema en producción es demasiado serio como para esperar que la suerte siempre esté de nuestro lado.
Nada es infalible, las pruebas de regresión tampoco (lo más probable es que en sistemas con un tamaño moderado no exista la posibilidad de invertir el esfuerzo necesario para definirlas y/o ejecutarlas pero siempre se debe llegar al mínimo de probar todas las funcionalidades esenciales y críticas del sistema) pero cuanto más precavidos seamos menos sorpresas desagradables nos encontraremos después.
Jummp 