Caso FIT · PAT-02
Generación de casos de prueba con IA
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é
Cómo funciona
- El analista pega el texto de la solicitud tal como llegó, con su referencia de ticket.
- El modelo lo convierte en una especificación estructurada: tipo de cliente, expedientes, créditos, moneda, producto y formatos de salida.
- La especificación marca lo que la solicitud no dice; el modelo no inventa valores y el analista revisa, corrige y aprueba.
- 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.
- Genera el reporte de crédito en cada formato pedido y entrega un paquete descargable por caso.
- 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
| Indicador | Cómo se mide | Resultado |
|---|---|---|
| Tiempo para generar un caso de prueba completo | Có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 analista | Có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ón | Có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 entrega | Cómo se mideConteo de paquetes devueltos o rehechos por error de datos o formato, por mes. | ResultadoSe mide en el piloto. |
Lecciones
- 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.
- 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ó.
- 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