La especificación también está en la forma de trabajar
El código puede mostrar qué hace un programa sin explicar por qué alguien depende de ese comportamiento. Una pantalla que parece redundante quizá permite una comprobación manual que nunca se documentó. Antes de retirarla o sustituirla, pedimos recorrer el proceso con sus usuarios.
En proyectos COBOL para Navarra proponemos convertir esas observaciones en escenarios de aceptación. Cada escenario describe una situación, una acción y un resultado verificable. Así se evita que la migración se valide únicamente mediante nombres de programas que no significan nada para quien usa la aplicación.
Excepciones que merecen su propio caso de prueba
La operación habitual suele ser fácil de demostrar. Las dificultades aparecen en anulaciones, rectificaciones, periodos cerrados o referencias que ya no están activas. Preguntamos qué procedimientos manuales existen para esas situaciones y qué parte realiza el programa.
No trasladamos automáticamente una solución manual al sistema nuevo ni la eliminamos sin acuerdo. Se documenta como una decisión. El plan de pruebas incorpora las excepciones que la empresa considera relevantes y señala cuáles todavía no pueden reproducirse con la información disponible.
Llevar el comportamiento a C# y .NET
Al desarrollar el destino, relacionamos sus funciones con los escenarios aprobados. Eso permite cambiar la organización interna del código sin perder la referencia al uso real. Las pruebas técnicas complementan esa validación, pero no la sustituyen.
Si se propone una interfaz diferente, revisamos el recorrido completo de la tarea. Que el cálculo sea correcto no basta cuando el usuario no puede identificar el registro que debe seleccionar o no entiende si una operación ya ha terminado. La experiencia de uso forma parte del alcance cuando se modifica.
IA para preparar borradores que el equipo pueda discutir
Claude, de Anthropic, y herramientas de OpenAI pueden apoyar la extracción de reglas y la propuesta de escenarios a partir de código autorizado. Pedimos que las dudas aparezcan explícitamente. Una regla inferida no se convierte en requisito hasta que se comprueba.
La revisión funcional se realiza con lenguaje que entienda el responsable del proceso. No le pedimos que apruebe una respuesta de IA extensa llena de referencias técnicas; le mostramos los casos que afectan a su trabajo y el resultado que obtendrá en cada uno.
Una aceptación que no dependa de la memoria
La entrega recoge qué versión se probó, con qué datos y qué diferencias quedaron aceptadas. Si cambia un requisito después, se puede localizar el escenario correspondiente y actualizarlo. Esto reduce la ambigüedad entre una incidencia y una petición nueva.
Un ejemplo hipotético sería sustituir un proceso de autorización conservando las excepciones que tramita un responsable. El piloto se centraría en demostrar esos recorridos antes de extenderlo a otras funciones. No es una referencia comercial ni un proyecto atribuido a una organización navarra.