Reescribir una aplicación heredada sin poner en riesgo el negocio: el método de las pruebas de paridad

Su aplicación lleva años en funcionamiento. Es lenta, difícil de modificar y quizá ya no del todo segura. Pero funciona, y su negocio depende de ella. Modernizarla impone respeto, y con razón: muchas reescrituras fracasan por el mismo motivo.

El verdadero riesgo: las reglas de negocio invisibles

Una aplicación heredada concentra años de decisiones: una forma particular de calcular un importe, una excepción para un tipo de cliente, un documento generado en un caso concreto. Estas reglas de negocio rara vez están todas documentadas. Viven en el código y en la cabeza de unos pocos usuarios.

En una reescritura de golpe, del tipo «big bang», algunas de estas reglas se olvidan. Nadie se da cuenta hasta después de la puesta en producción, cuando un cliente recibe una factura errónea o un expediente se queda bloqueado.

El principio de las pruebas de paridad

Una prueba de paridad describe un comportamiento de la aplicación visto desde fuera: cuando hacemos esto, debemos obtener aquello. Por ejemplo: «cuando una factura se paga por completo, el pedido pasa al estado saldado».

La idea clave es sencilla:

1. La prueba se escribe en el lenguaje del negocio, con independencia de la tecnología.
2. Primero se ejecuta contra la aplicación antigua, para comprobar que describe de verdad la realidad.
3. Después, exactamente la misma prueba se ejecuta contra la nueva aplicación. Mientras no la supere, la nueva versión no está lista.

En la práctica, las pruebas se apoyan en una fina capa intermedia que sabe «hablar» con la aplicación antigua y, después, en otra que sabe hablar con la nueva. Las pruebas en sí no cambian. Por eso constituyen una demostración sólida.

El método, paso a paso

1. Enumerar los comportamientos críticos con los usuarios: lo que nunca debe fallar (cálculos, estados, documentos, permisos de acceso).
2. Escribir las pruebas de paridad de estos comportamientos, empezando por los más importantes.
3. Validarlas contra la aplicación antigua: todas las pruebas deben superarse; si una no lo hace, la regla se ha entendido mal.
4. Reconstruir módulo a módulo. Cada parte reescrita debe superar las mismas pruebas que la antigua.
5. Hacer el cambio cuando se superen todas las pruebas, con una migración de datos verificada y una vigilancia estrecha durante las primeras semanas.

«¿Error o regla?»: la pregunta que siempre vuelve

Al escribir las pruebas, siempre aparecen comportamientos extraños. Algunos son errores que todo el mundo lleva años sorteando. Otros son reglas que alguien quiso en algún momento.

La respuesta correcta no es técnica: es una decisión de negocio. Estos casos se enumeran, se deciden con el responsable de esa parte de la actividad y cada decisión se documenta. La nueva aplicación corrige los errores de forma deliberada y conserva las reglas con conocimiento de causa.

Lo que se gana

• Confianza: sabe, y puede demostrarlo, que la nueva aplicación hace lo que hacía la antigua.
• Un avance medible: el número de pruebas que supera la nueva versión muestra en qué punto está el proyecto.
• Una red de seguridad para el futuro: las pruebas se quedan y protegen cada cambio posterior.

En resumen

Modernizar una aplicación no tiene por qué ser un salto al vacío. Con las pruebas de paridad, avanza paso a paso, sin perder ninguna regla de negocio y sin interrumpir su actividad.

¿Su aplicación empieza a acusar el paso de los años? Una llamada exploratoria de 30 minutos basta para ver si este enfoque se adapta a su situación.