Volver a los casos

Caso FIT · PAT-02

Generación de casos de prueba con IA

Caso de éxitoServicios de información financiera

Ejecutado con un cliente; los detalles se comparten en la sesión de diagnóstico.

Contexto

Ocurre en empresas de información financiera cuyos clientes necesitan datos de prueba realistas, pero ficticios, para probar sus integraciones. Aquí un caso de prueba no es un guion de pruebas: es un expediente ficticio de una empresa, con sus cuentas de crédito cargadas en el sistema legado y su reporte de crédito en varios formatos. El equipo de QA arma cada uno a mano, en sistemas que conocen pocas personas y con tickets a otras áreas.

El reto

El equipo de QA recibía en lenguaje natural pedidos de casos de prueba, cada uno un expediente ficticio de una empresa con cuentas de crédito y su reporte de crédito en varios formatos, y los armaba a mano en sistemas legados con consultas, cargas de datos y varias herramientas internas.

Cómo se resolvió

Un modelo interpreta el pedido y lo convierte en una especificación estructurada que señala lo ambiguo. El analista de QA revisa, corrige y aprueba. Solo entonces un agente ejecuta los pasos en orden: crea el expediente, asigna los créditos, genera los reportes en cada formato y entrega un paquete descargable. Cada caso queda registrado de punta a punta.

Roles

  • Analista de QA
  • Supervisor de QA
  • Administrador de base de datos
  • Equipo de TI del cliente que pide el caso

Antes y después

Antes

Armar cada caso a mano en sistemas legados, con tickets a otras áreas

Con IA

QA aprueba la interpretación y el agente arma el caso completo

Quién hace qué

Quién hace qué: Generación de casos de prueba con IAFlujo en 6 pasos, en carriles de personas, agentes de IA y sistemas. 1. Personas: Analista pega la solicitud recibida 2. Agentes de IA: Estructura el pedido y marca lo ambiguo 3. Personas: Analista corrige y aprueba 4. Agentes de IA: Ejecuta los pasos del caso 5. Sistemas: Crea expediente, créditos y reportes 6. Sistemas: Entrega paquete y registra cada pasoPersonasAgentesde IASistemasAnalistapega lasolicitudrecibidaEstructurael pedido ymarca loambiguoAnalistacorrige yapruebaEjecuta lospasos delcasoCreaexpediente,créditos yreportesEntregapaquete yregistracada paso
Quién hace qué: Generación de casos de prueba con IAFlujo en 6 pasos, en carriles de personas, agentes de IA y sistemas. 1. Personas: Analista pega la solicitud recibida 2. Agentes de IA: Estructura el pedido y marca lo ambiguo 3. Personas: Analista corrige y aprueba 4. Agentes de IA: Ejecuta los pasos del caso 5. Sistemas: Crea expediente, créditos y reportes 6. Sistemas: Entrega paquete y registra cada pasoPersonaAnalista pega la solicitud recibidaAgente de IAEstructura el pedido y marca loambiguoPersonaAnalista corrige y apruebaAgente de IAEjecuta los pasos del casoSistemaCrea expediente, créditos y reportesSistemaEntrega paquete y registra cada paso

Cómo funciona

  1. El analista pega el texto de la solicitud tal como llegó, con su referencia de ticket.
  2. El modelo lo convierte en una especificación estructurada: tipo de cliente, expedientes, créditos, moneda, producto y formatos de salida.
  3. La especificación marca lo que la solicitud no dice; el modelo no inventa valores y el analista revisa, corrige y aprueba.
  4. Solo con esa aprobación, el agente ejecuta los pasos en orden: crea el expediente, asigna los créditos y los deja disponibles para búsqueda.
  5. Genera el reporte de crédito en cada formato pedido y entrega un paquete descargable por caso.
  6. Cada paso queda en un registro de auditoría con entrada, interpretación, ejecución, salidas y usuario; si un paso falla se reintenta sin duplicar expedientes.

Sistemas

  • Sistema central legado y su base de datos
  • Índice de búsqueda
  • Generador de reportes del sistema central
  • API de servicios a clientes
  • Herramienta interna de alta de expedientes
  • Almacenamiento de archivos

Capacidades

  • Generación y ejecución de pruebas de software
  • Orquestación de agentes en tareas de varios pasos

Criterios de éxito

IndicadorCómo se mideResultado
Tiempo para generar un caso de prueba completoCómo se mideTiempo para armar un caso completo, manual contra automatizado, del pedido aprobado al paquete entregado.Resultado medidoDe 3 a 4 horas a entre 10 y 30 segundos por caso, medido en la PoC sobre sistemas emulados.
Porcentaje de interpretaciones aprobadas sin corrección del analistaCómo se mideCasos cuya especificación se aprobó sin editar campos, sobre el total de casos aprobados.ResultadoSe mide en el piloto.
Porcentaje de casos ejecutados de punta a punta sin intervenciónCómo se mideCasos con todos sus pasos completados en el registro de ejecución, sin reinicio manual, sobre los aprobados.ResultadoSe mide en el piloto.
Casos rechazados por el solicitante tras la entregaCómo se mideConteo de paquetes devueltos o rehechos por error de datos o formato, por mes.ResultadoSe mide en el piloto.

Lecciones

  1. Una PoC diseñada desde el inicio para reutilizarse se convierte en el acelerador del proyecto productivo; una PoC desechable obliga a empezar de cero.
  2. El modelo no completa lo que la solicitud no trae: lo marca como ambiguo y decide el analista; así el caso generado se puede defender frente a quien lo pidió.
  3. Una secuencia fija de pasos conviene ejecutarla en código como una sola acción del agente; repartida en muchas herramientas chocó con los límites de la plataforma y se volvió frágil.

Controles clave

Ambientes separados y datos de prueba seguros · Datos de evaluación representativos · Set de evaluación propio antes de producción · Gestión de cambios de prompts, herramientas y modelos

Implementación de referencia: Implementado sobre watsonx Orchestrate y watsonx.ai.

Quiero revisar esto con FIT: Felipe Arentsen · felipe.arentsen@factorit.com

FIT Labs · La Fábrica de Soluciones