Desarrollo con agentes de IA (ADLC): dónde encaja GUI Test Studio
Los agentes de programación con IA planifican, escriben, prueban, corrigen y entregan, con personas al mando: el ciclo de vida del desarrollo agéntico, o ADLC.Dónde encajan las pruebas end-to-end en ese ciclo, y cómo GUI Test Studio da a un agente una prueba que puede crear desde una petición, cambiar en el sitio, ejecutar sin ventana y en paralelo en cualquier pipeline de CI/CD, leer como un veredicto en palabras sencillas y registrar en Jira, hasta que el ciclo se cierra.
9 min de lecturaPor el equipo de GUI Test Studio
Qué es el ciclo de vida del desarrollo agéntico (ADLC)
Durante décadas el software se construyó siguiendo el ciclo de vida del desarrollo de software, el SDLC: un equipo planifica, un desarrollador programa, un tester prueba, alguien corrige, alguien entrega, y el ciclo vuelve a empezar.Los agentes de programación con IA no han sustituido ese ciclo.Se han hecho cargo de su bucle interno.
En un ciclo de vida del desarrollo agéntico, el ADLC, un agente como Claude Code, Codex, Claude Desktop o Copilot en modo agente lee la tarea, planifica el cambio, escribe el código, ejecuta las pruebas que puede, corrige lo que falla y abre una pull request, a menudo varias veces por hora.Las personas fijan el objetivo, revisan lo que sale y deciden qué se entrega.El ciclo gira mucho más rápido que antes, y la calidad de lo que se entrega depende de la calidad de lo que el agente puede comprobar por sí mismo.
Los agentes son buenos en las comprobaciones que viven en el código: pruebas unitarias, comprobaciones de tipos, linters.Son ciegos a lo único que ve un usuario: la aplicación en funcionamiento, en una pantalla real, a través de su interfaz real.Ahí es donde encajan las pruebas end-to-end, y donde la mayoría de los ciclos de agentes todavía tienen un hueco.
Dónde encajan las pruebas end-to-end
Una prueba end-to-end maneja la aplicación como lo haría un usuario: la abre, hace clic y escribe a lo largo de un flujo completo, y verifica lo que muestra la pantalla.Para un agente es la verdad de referencia que el código no puede dar: si el botón sobrevivió al nuevo estilo, si el formulario sigue enviándose, si el total sigue siendo correcto.
Tres cosas han mantenido las pruebas end-to-end fuera de los ciclos de los agentes.Eran lentas de escribir, así que nadie escribía una para un cambio hecho en diez minutos.Eran código ellas mismas, así que se rompían con cada elemento renombrado.Y sus resultados eran un muro de registros a partir del cual un agente tenía que adivinar.
GUI Test Studio elimina las tres.Una prueba se graba o se describe, nunca se programa.Encuentra los elementos con el GTS Engine + AI, mediante lo que la aplicación dice de ellos, su información de accesibilidad, y visualmente cuando no dice nada, así que un nombre de clase cambiado no rompe nada.Y cada ejecución termina en un Informe de confianza escrito en palabras sencillas, que un agente lee con la misma facilidad que una persona.El resto de este artículo sigue el ciclo, etapa por etapa.
| Etapa | Qué hace el agente | Con GUI Test Studio |
|---|---|---|
| Planear | Lee la tarea y decide qué comprobar | Describe en una petición el flujo de trabajo que hay que probar, o parte de un diseño de Figma |
| Programar | Escribe el cambio | Nada que hacer: ningún código de prueba que escribir ni actualizar |
| Probar | Ejecuta las pruebas que tiene | Graba una prueba end-to-end real a través del conector y luego la ejecuta con gtr-cli |
| Verificar | Lee los resultados | Lee el Informe de confianza: encontrado o no, cambiado o igual, en palabras sencillas |
| Corregir | Vuelve a cambiar el código | Retoma la incidencia de Jira que registró la ejecución fallida, con sus pasos y sus imágenes |
| Entregar | Abre la pull request | El pipeline ejecuta todas las pruebas en cada build, sin ventana y en paralelo |
Crear: una prueba end-to-end desde una petición
Instale GUI Test Studio y conecte su asistente una vez: en GUI Test Runner-Recorder, Crear test desde una petición muestra Claude Desktop, Claude Code y VS Code, cada uno con un botón Conectar.Cualquier otro asistente que hable el protocolo del conector está a un comando de distancia.
Después describa la prueba.El agente la graba como lo haría un tester: abre la aplicación o la página web, hace clic en los botones reales, escribe en los campos reales y verifica lo que ve sobre la marcha, a través del conector.Cada comprobación se evalúa en el momento, en la pantalla real, y se rechaza cuando no se superaría ahora mismo, así que el agente nunca guarda una comprobación que esté mal desde el primer día.
Su asistente
Grabando la prueba en su pantalla
- •Tienda abierta y sesión iniciada
- •Lámpara de escritorio añadida, carrito abierto
- •Total verificado: $49.00 está en la pantalla
- •Checkout.GTS guardado y ejecutado: PASSED
Lo que sale es una prueba corriente de GUI Test Studio, con la misma grabación, los mismos pasos y las mismas comprobaciones que habría hecho una persona, guardada donde usted elija.Por el camino, el agente puede pausar para pensar, deshacer un paso que salió mal, agrupar pasos en escenarios, añadir una espera o una nota, y ejecutar la prueba al final para demostrar que se supera.
With GUI Test Studio, create an end-to-end test of the shop at http://localhost:8080:
sign in as [email protected], add the "Desk lamp" to the cart, open the cart,
and verify that the total reads "$49.00" and that the "Checkout" button is shown.El agente prueba lo que usted le indique: toda la pantalla, una aplicación, un área de ella, una página web en el navegador que elija, o un teléfono conectado.No explora nada sin que se lo pidan.Cómo conectar cada asistente y qué pedirle está en Crear una prueba desde una petición.
Editar: cambiar una prueba por petición, o como un vídeo
Las pruebas envejecen con la aplicación.Cuando el agente renombra un botón o añade un campo, también debería actualizar la prueba, no grabar una nueva.
A través del conector, el agente enumera los pasos de una prueba por número y los cambia en el sitio: renombrar un paso, cambiar el texto que espera una comprobación, dar más tiempo a una comprobación, quitar un paso o ignorarlo, añadir una espera, decir qué pasa si una comprobación falla.Nada se escribe antes de que el agente muestre los cambios y usted los confirme, y la prueba conserva todo lo demás exactamente como estaba.
Una persona hace lo mismo en GUI Test Studio, en una línea de tiempo: los pasos son bloques que se mueven, recortan, renombran y agrupan, con deshacer para todo, y el fotograma de la grabación bajo cada uno.La prueba del agente y la prueba del tester son el mismo archivo, como muestra Actualizar una prueba.
Ejecutar: sin ventana, en paralelo, en cualquier pipeline de CI/CD
gtr-cli ejecuta cualquier prueba de GUI Test Studio sin ventana, desde un script o un pipeline, y responde como espera un pipeline: un código de salida, un archivo JUnit para la herramienta de CI, un archivo JSON para un script, un resumen en Markdown para la pull request.
gtr-cli run tests --countdown 0 --format github --junit results\junit.xml ^
--json results\run.json --summary results\summary.md --artifacts results\artifacts ^
--jira on-failureUna prueba web grabada una vez puede generarse para otros navegadores y dispositivos: Chrome, Edge y Firefox, teléfonos, tabletas y tamaños de pantalla, otro idioma, una red lenta, un nivel de zoom.Los navegadores y dispositivos que no necesitan ventana se ejecutan en paralelo, cada uno en un proceso propio, y una prueba de escritorio se ejecuta en su ventana después de ellos.Consulte Navegadores y dispositivos.
El registro habla el protocolo propio de cada herramienta: --format teamcity, azure, github o texto sin formato.El mismo comando funciona en TeamCity, Jenkins, GitHub Actions, GitLab, Azure DevOps o un script propio, como muestra paso a paso Ejecute sus pruebas end-to-end en cada build.
| Opción | Qué le da al agente |
|---|---|
| --json | Un archivo con cada prueba, paso y veredicto, el motivo de cada fallo y las conclusiones de la IA: lo primero que lee un script o un agente |
| --junit | Las pruebas como pruebas en TeamCity, Jenkins, GitHub Actions, GitLab o Azure DevOps |
| --summary | Un resumen para pegar en la pull request |
| --artifacts | El vídeo, las imágenes y el informe de defecto de cada fallo, en una sola carpeta |
| --retries | Volver a ejecutar una prueba fallida antes de darla por fallida |
| --branch all | Todos los navegadores y dispositivos para los que se generó la prueba, en un solo build |
Leer: un veredicto que entienden tanto un agente como una persona
Cada ejecución termina en un Informe de confianza.Para cada comprobación dice, en palabras sencillas, si se encontró el elemento, si lo encontrado coincide con la grabación y cuánto margen hubo: una comprobación superada por poco es un aviso antes de convertirse en un fallo.
El Análisis inteligente con IA, el lado de IA del GTS Engine + AI, examina una comprobación que falló por píxeles y distingue una regresión real del ruido: una palabra cambiada, una insignia que falta u otro color son una regresión; un matiz o un desplazamiento de un píxel no lo son.Su respuesta es el veredicto final, y viene con una frase sobre la que un agente puede actuar: qué cambió, dónde y cuánto.
Un agente lee el archivo JSON y el resumen en Markdown que escribe la ejecución; una persona abre el informe, con las imágenes una junto a otra, el vídeo de la ejecución y el historial de la prueba.Ambos dicen lo mismo.El informe se describe en Leer el Informe de confianza.
Corregir: un bug de Jira que el agente puede retomar
Con --jira on-failure, una prueba fallida se convierte por sí sola en una incidencia de Jira: un título, los pasos numerados para reproducir, la imagen que esperaba la prueba, la imagen que encontró y esa misma imagen con cada cambio resaltado, además de un PDF y las evidencias.El mismo defecto visto de nuevo, en otro build, navegador o dispositivo, añade un comentario a su incidencia abierta, nunca un duplicado.
Esa incidencia está escrita para un desarrollador, y resulta ser exactamente lo que necesita un agente de programación: un camino reproducible, una expectativa precisa y una imagen de la diferencia.Señale la incidencia al agente y tendrá todo lo necesario para proponer una corrección.Cómo se conecta Jira, desde el Informe de confianza o desde un pipeline, está en cada prueba end-to-end fallida se convierte en un bug de Jira.
El ciclo, cerrado: una tienda de demostración
Construimos una pequeña demostración para ver girar el ciclo completo: una tienda en línea, su prueba end-to-end, un servidor de TeamCity, un proyecto de Jira y un agente de programación con IA.Jean es el desarrollador, Pierre escribió la prueba, James se ocupa del backlog, John gestiona TeamCity.
Jean sube un cambio
Un nuevo estilo para el pago
TeamCity ejecuta la prueba
Con gtr-cli
El pago falla
Una incidencia de Jira, con imágenes
El agente lo corrige
En una rama propia
La prueba se supera
Una persona revisa y fusiona
- 1
Un cambio rompe el pago
Jean sube un nuevo estilo para los botones del pago.TeamCity ejecuta la prueba end-to-end de la tienda con gtr-cli, sin ventana, en todos los navegadores y dispositivos para los que se generó la prueba.
- 2
La ejecución dice qué se rompió, y dónde
El Informe de confianza encuentra el botón de pago, pero no como se grabó.El Análisis inteligente con IA confirma una regresión real: el botón perdió su etiqueta. gtr-cli registra una incidencia de Jira con los pasos, las imágenes esperada y encontrada y el cambio resaltado, y el registro de build de TeamCity nombra la incidencia.
- 3
El agente lo corrige
El agente retoma la incidencia, lee los pasos y las imágenes, encuentra la regla de estilo que ocultó la etiqueta y propone una corrección en una rama propia.
- 4
La prueba demuestra la corrección
TeamCity ejecuta la misma prueba en la rama.Se supera.La ejecución superada se añade a la incidencia de Jira, y James la cierra una vez que una persona ha revisado y fusionado el cambio.Nadie escribió a mano una prueba, un informe de defecto ni una reproducción.
El lado humano
Un ADLC no son solo agentes.Las personas que lo dirigen necesitan confiar en lo que comprueban los agentes, y comprobarlo ellas mismas cuando importa.GUI Test Studio se construyó para eso: la misma prueba sirve al agente y a la persona.
| Para | Qué obtienen |
|---|---|
| Testers | Una prueba que leen como un vídeo: una línea de tiempo de pasos con el fotograma bajo cada uno, sin código.Graban un flujo de trabajo en dos minutos, y el agente del desarrollador lo ejecuta en cada build |
| Desarrolladores | Un fallo que dice qué cambió, dónde, con las imágenes una junto a otra, y una incidencia de Jira sobre la que su agente puede actuar |
| Responsables de producto | Un veredicto en palabras sencillas: encontrado o no, cambiado o igual, y un historial de cada ejecución |
| Seguridad y TI | Pruebas, grabaciones y resultados que se quedan en sus equipos Windows; el GTS Engine + AI se ejecuta ahí, y la IA se ejecuta en su propio equipo o en la nube con su propia clave |
En sus instalaciones o en la nube, la elección es suya, comprobación por comprobación.Un agente que crea pruebas, un tester que las lee y un pipeline que las ejecuta están mirando el mismo archivo, con las mismas palabras.
Por dónde empezar
¿Listo para grabar su primera prueba?
Todas las funciones, durante 15 días.
¿Prefiere verlo con el tipo de aplicación que prueba?Reserve una llamada gratuita de 30 minutos con nuestro equipo.