Antes de mejorar, saber qué resultado se está conservando
Cuando no existe una especificación completa, puede ser útil preparar pruebas que describan lo que hace la aplicación actual. No convierten todos sus comportamientos en correctos; crean una referencia para detectar cambios y decidir cuáles son intencionados.
Para un proyecto en Granada empezamos por funciones observables. Recogemos entradas y salidas, anotamos las condiciones del entorno y preguntamos qué resultados utiliza el negocio. La referencia debe ser repetible, no una captura aislada de una ejecución que nadie puede reconstruir.
Elegir muestras que descubran diferencias
Los ejemplos habituales son necesarios, pero no suficientes. Revisamos límites de longitud, valores ausentes, registros repetidos y combinaciones que activan caminos alternativos. La selección depende de la operación, no de una lista genérica de pruebas idéntica para todos los programas.
Cuando una salida incorpora valores variables, se identifica qué parte puede compararse directamente. Las normalizaciones se justifican por escrito para no ocultar precisamente el dato que habría permitido detectar un error.
Comparar COBOL con una implementación en C#
Durante el piloto de migración ejecutamos ambas versiones con información equivalente y conservamos las diferencias. El informe debe permitir distinguir cambios de formato, datos de entrada distintos y alteraciones funcionales.
La validación no termina en una función aislada. Incluimos la preparación de datos y la entrega de resultados cuando forman parte del alcance. Una conversión correcta puede fallar si el nuevo lector interpreta de otra manera el archivo original.
Evitar que la IA se examine a sí misma
Las herramientas de OpenAI o Claude, de Anthropic, pueden proponer código y pruebas, pero ambas salidas necesitan una referencia externa. Si la misma interpretación incorrecta aparece en la implementación y en el resultado esperado, una prueba puede aprobar sin demostrar equivalencia.
Por eso contrastamos las expectativas con el sistema original y con reglas confirmadas por el cliente. Se revisan también los supuestos que la herramienta haya añadido para completar una especificación insuficiente.
Una biblioteca de pruebas aprovechable después
El resultado no tiene por qué limitarse a aprobar una migración. Las pruebas pueden seguir utilizándose para revisar cambios de mantenimiento y detectar regresiones. Dejamos descrita la forma de ejecutarlas y de actualizar una expectativa cuando cambia un requisito.
Un ejemplo ilustrativo sería documentar primero un cálculo de comisiones antes de sustituirlo. El objetivo del piloto sería identificar diferencias con precisión, no anunciar que el nuevo código es mejor por utilizar otro lenguaje. No se atribuye el ejemplo a una empresa granadina.