Cómo probar una política antes de producción: test de nodos, debug y promoción

Probar un nodo en aislamiento

El primer nivel de prueba es el nodo suelto: ejecutarlo sin correr toda la política ni guardarla. La configuración de test de uFlow permite cargar los valores de entrada de dos maneras:

El resultado es la lista de variables de salida con sus valores y tipos: suficiente para validar una matriz, una calculadora o un parser sin tocar nada más.

• Carga manual: se tipean los valores de las variables que el nodo necesita.
• Carga desde transacción: con el identificador de una transacción previa se importan sus variables, sujeto a los permisos del usuario y a las políticas de protección de datos de la institución — útil para reproducir un caso puntual.

Depurar el flujo completo, paso a paso

El segundo nivel es el modo debug: ejecutar la política entera avanzando nodo por nodo, con el panel de variables mostrando cómo cambia cada valor en cada paso.

Los controles permiten avanzar, retroceder, saltar un nodo o correr hasta un punto específico. Y hay un truco potente: se puede modificar el valor de una variable en medio de la ejecución para forzar un camino — por ejemplo, simular que el bureau falló y verificar que el camino de contingencia hace lo que debe, sin esperar a que falle de verdad.

El checklist antes de promover

Antes de publicar una versión nueva, la evidencia mínima que debería existir:

• Todos los caminos ejercitados en debug, incluidos los de error y contingencia.
• Matrices y ramas con cobertura completa: ningún caso posible sin respuesta.
• Los casos límite del negocio probados con casos representativos — datos anonimizados o sintéticos que repliquen la estructura de los reales.
• Si el cambio es de fondo: champion/challenger sobre una porción del tráfico antes de adoptarlo al 100%.
• La aprobación de quien corresponde, con los permisos de edición y ejecución separados por rol.

Promoción y marcha atrás

Publicar es crear una versión nueva identificable, no pisar la anterior: si algo sale mal, el rollback a la versión previa es inmediato y el registro de transacciones identifica exactamente qué decisiones tomó la versión defectuosa.

Para flujos con ambientes separados, las políticas se exportan e importan como archivo: lo que se probó en el ambiente de prueba es literalmente lo mismo que se publica en producción. Y después de publicar, las primeras horas se monitorean: tasa de aprobación, errores por proveedor y caminos ejecutados.