Probar el workflow con casos y fallos

Un workflow no se valida porque el camino feliz funcione una vez. Debe demostrar qué ocurre con datos incompletos, duplicados, respuestas tardías, reglas conflictivas y componentes indisponibles. La prueba útil intenta romper las hipótesis del diseño antes de que lo hagan los casos reales.

El NIST AI RMF recomienda, de forma voluntaria, medir y monitorizar sistemas de IA de acuerdo con su contexto y riesgos. Los principios de fiabilidad de arquitectura también insisten en diseñar y comprobar recuperación ante fallos. En este curso utilizaremos esas ideas sin convertirlas en una receta universal.

Convierte el mapa en escenarios

Cada ruta del workflow debería tener al menos un caso de prueba. Cada excepción importante, también.

Un escenario necesita:

• estado inicial;
• datos de entrada;
• evento;
• dependencias disponibles o fallidas;
• resultado esperado;
• estado final;
• efectos que deben producirse;
• efectos que no deben producirse;
• evidencia necesaria para verificarlo.

No te limites a “esperado: funciona”. Define qué significa funcionar.

Construye una cartera equilibrada

Camino normal

Casos representativos que deberían completarse sin intervención extraordinaria.

Límites

Valores en el borde de reglas: exactamente el umbral de descuento, fecha límite, máximo de elementos, campo opcional vacío.

Variantes

Rutas legítimas diferentes: cliente nuevo, solicitud internacional, producto sin stock.

Excepciones

Datos contradictorios, documento ilegible, clasificación de IA fuera de categorías permitidas o aprobación rechazada.

Fallos técnicos

Timeout, 429, 503, pérdida temporal de conexión, webhook duplicado o servicio externo indisponible.

Concurrencia y duplicados

Dos eventos para el mismo caso, doble clic de aprobación, dos workers procesando la misma intención o respuesta tardía después de un retry.

Recuperación

Casos donde el sistema debe reanudar después de fallo, reconciliar una acción incierta o devolver el trabajo a una persona.

Verifica invariantes y efectos negativos

Una prueba no solo comprueba lo que debe ocurrir. También debe comprobar lo que no puede ocurrir.

Ejemplo:

• el presupuesto se crea una vez;
• no se envía sin aprobación;
• un retry no crea una segunda versión;
• un caso cancelado no reanuda por un evento tardío;
• una aprobación de v2 no puede aplicarse a v3;
• un error de IA no modifica el ERP.

Estas condiciones son especialmente valiosas porque detectan fallos que una prueba superficial puede pasar por alto.

Prueba reglas e IA por separado

Si una ruta combina IA y reglas, separa sus evaluaciones.

Para la parte determinista puedes comprobar entradas y salidas exactas. Para una clasificación con IA necesitas un conjunto de casos representativos, criterios de aceptación y revisión de errores.

No uses una única muestra “que salió bien”. Conserva un conjunto reutilizable que permita detectar regresiones cuando cambie el prompt, el modelo o el preprocesamiento.

Inyecta fallos de forma controlada

No hace falta tumbar producción para probar resiliencia. Durante desarrollo o staging puedes simular:

• latencia artificial;
• respuesta inválida;
• timeout;
• error reintentable;
• error permanente;
• evento duplicado;
• pérdida de confirmación;
• dato ausente.

El objetivo es verificar que la máquina de estados y la política de recuperación responden como se diseñó.

Ejemplo: doble solicitud y timeout

Una solicitud se recibe dos veces porque el proveedor reenvía el webhook. El workflow debería reconocer la identidad del caso o evento y no generar dos presupuestos.

Durante la consulta al ERP se produce timeout. El sistema no debe asumir automáticamente que la operación falló. Si es una lectura, puede reintentar según política. Si fuera una escritura, debería consultar estado o reconciliar antes de repetir.

La prueba termina solo cuando puedes verificar estado final, efectos y evidencia.

Define criterios de salida

Antes de considerar el workflow preparado para implementación, establece qué debe pasar.

Ejemplo de criterios:

• 100 % de rutas críticas cubiertas por escenarios;
• ninguna violación de invariantes;
• duplicados controlados en operaciones con efectos;
• excepciones con propietario;
• recuperación demostrada para dependencias principales;
• conjunto de evaluación de IA conservado y versionado;
• observabilidad suficiente para diagnosticar fallos probados.

Las cifras concretas dependen del proceso. No adoptes porcentajes de ejemplo sin contexto.

Ejercicio: matriz de pruebas

Crea al menos 15 escenarios repartidos entre camino normal, límites, variantes, excepciones, fallos, duplicados y recuperación.

Para cada uno registra:

Selecciona cinco como conjunto mínimo de regresión que deberá ejecutarse tras cualquier cambio importante.

Resultado de la lección

El diseño ya ha sido sometido a situaciones adversas antes de convertirse en sistema real. Tienes una cartera reproducible de escenarios, invariantes y criterios de salida. El último paso consiste en consolidar todo lo aprendido en un blueprint que otra persona pueda implementar sin reconstruir decisiones implícitas.