Un agente de IA con GPT-5.5 revisó 2600 autotests de TravelLine en dos semanas

Ilsur Mingazov, tester de TravelLine, realizó junto con un agente de IA una auditoría de los autotests de la plataforma para hoteles en dos semanas. Unos 2600 tests de una base de 6500 escenarios E2E pasaron por un análisis semántico, y las estadísticas de ejecución se recopilaron para toda la base. El motivo fue la migración prevista de los tests de Java a .NET. El equipo concluyó que trasladarlos «tal cual» arrastraría al nuevo stack la deuda técnica acumulada durante 15 años. Como resultado, en la sección de tests de capturas de pantalla se eliminaron unos 450 tests obsoletos y, en varias secciones, se crearon tareas para escribir tests de integración.

El entorno del agente: código, MCP y elección del modelo

Una lista de nombres de escenarios del TMS no basta para un trabajo así, de modo que se le dio al agente el contexto completo. El entorno de trabajo era este:

• OpenCode: el entorno en el que funciona el agente.
• Repositorios locales: clones del producto y del proyecto de autotests. El agente recorre las carpetas por sí mismo, busca métodos y clases y relaciona las llamadas, sin copiar nada manualmente al contexto.
• TestIT mediante MCP: primero probaron con consultas directas a la API y después pasaron a un servidor MCP. El agente invoca herramientas ya preparadas y el servidor obtiene entidades, metadatos y ejecuciones.
• GPT-5.5: la eligieron del catálogo de OpenCode. Descartaron de entrada las versiones ligeras tipo Flash, que perdían detalles al relacionar la arquitectura con lógica compleja. GPT-5.5 mantenía un prompt largo con las reglas de la pirámide de tests, llamaba con precisión a las herramientas MCP y no inventaba vínculos entre tests y código.
• Prompt de sistema y contrato de respuesta: los criterios para separar E2E de integration, más un formato estricto de informe en markdown, sin relleno.

La primera prueba fue la del propio agente. Al pedirle que analizara una sección, devolvió una lista incompleta. Los logs de razonamiento mostraron que se había guiado por los conjuntos de tests (suites), mientras que el tester esperaba el árbol de secciones y subsecciones. Ayudaron una captura de pantalla del árbol y una explicación detallada de dónde obtener los tests. Después, el equipo fijó ese procedimiento en las instrucciones del agente.

Primera iteración: migrar, bajar de nivel o no tocar

En skill.md había que asignar a cada test una de tres etiquetas:

• MIGRATE_TO_NET: escenario vigente, que se traslada al framework de .NET tal cual;
• SHIFT_TO_INTEGRATION: lógica de negocio o API que conviene entregar a los desarrolladores de backend para tests de integración;
• OBSOLETE_OR_BROKEN: la funcionalidad se eliminó o cambió, el test está roto, duplica a otro o es redundante como comprobación de UI; no se migra.

El agente asignaba a E2E el happy path crítico, los recorridos completos del usuario, las conexiones entre subsistemas, la navegación y la visualización. A integration enviaba los cálculos, la validación de combinaciones de datos, el guardado de ajustes y los límites, es decir, todo aquello en lo que el navegador solo ralentiza la ejecución.

Un ejemplo claro es la sección Transfers. De sus 18 tests E2E, el agente relacionó los escenarios con los tests de integración existentes y comprobó que 15 duplicaban comprobaciones del nivel inferior, pero a mayor coste y con más riesgo de fallos inestables. Resultado: 3 tests en MIGRATE_TO_NET, 0 en SHIFT_TO_INTEGRATION y 15 en OBSOLETE_OR_BROKEN. Una migración directa habría llevado a .NET 15 escenarios superfluos: más tiempo de ejecución, más fallos que analizar y más código que mantener.

Segunda iteración: P85 de fallos y duración

El código no muestra con qué frecuencia falla un test ni cuánto tarda realmente. Por eso, para cada uno de los ~6500 tests se pidieron a TestIT hasta 100 resultados recientes, que se agruparon por secciones. Se calcularon dos indicadores:

• fail rate: proporción de resultados Failed sobre el total; por ejemplo, 10 de 100 equivale a 10%;
• P85 de duración: calculado sobre las ejecuciones con estado Passed; las fallidas no se tuvieron en cuenta, para que los timeouts no distorsionaran el resultado.

Dentro de cada sección se calcularon los umbrales P85 de ambos indicadores y salieron cuatro grupos: solo fallos frecuentes, solo tests lentos, la intersección y el resto. La intersección se revisó primero. Con todo, un test lento no siempre es malo, y los fallos frecuentes pueden deberse al producto o al entorno. Las estadísticas servían para ordenar la cola de revisión, no para dictar sentencia.

En la sección reports, el agente contó 245 tests, 24 051 ejecuciones y 1598 fallos, es decir, un fail rate de 6,6%. Solo por fallos, 29 tests entraron en la zona problemática; solo por duración, 28; por ambos criterios, 9. Para estos nueve el agente preparó un informe en DOCX y Markdown (passed / failed / P85 passed en segundos):

• modificación de los parámetros de un pedido — 87 / 11 / 131,0;
• cancelación de una operación con recálculo parcial — 86 / 11 / 102,0;
• filtrado de datos por parámetros — 88 / 10 / 308,0;
• comprobación de la zona horaria en los informes — 78 / 10 / 170,9;
• comprobación de la periodicidad en las exportaciones — 75 / 11 / 162,0;
• confirmación del estado de una entidad — 74 / 11 / 144,1;
• finalización de la tramitación de un pedido — 75 / 9 / 169,8;
• envío de notificaciones transaccionales — 70 / 19 / 240,1;
• procesamiento de un pago y ejecución de un reembolso — 63 / 33 / 253,7.

Qué pueden aprovechar otros equipos

El papel de la persona en el proceso no cambió: fijar los criterios, verificar las conclusiones del agente y discutir los casos complejos con los desarrolladores. El agente se encargó de buscar archivos, leer código, relacionar comprobaciones y recopilar estadísticas. El resultado no fue un informe, sino un conjunto de tareas. Se eliminaron los duplicados, se borraron unos 450 tests de capturas de pantalla, se crearon tareas para tests de integración y para migrar los escenarios ya verificados, y el resto de las secciones quedaron en cola para discutirse.

Para equipos con una base de tests grande, la lección es práctica. El agente necesita acceso al código y al sistema de gestión de tests mediante MCP, no una exportación de nombres. Las etiquetas de decisión aportan más que las descripciones, y conviene incluir en el plan una verificación inicial del propio agente. Los tests que son a la vez lentos e inestables conviene revisarlos primero. Un agente ya configurado, con reglas de análisis, sigue en el equipo y puede analizar fallos, buscar la cobertura existente y evaluar nuevos escenarios sin tener que reconstruir el contexto.