Cómo ejecutar agentes de control de calidad en cada solicitud de extracción con QA.tech (sin escribir un solo guion de pruebas)
Si tu equipo ha adoptado herramientas de programación con IA, ya conoces las incómodas cifras. Los equipos de ingeniería que antes entregaban un puñado de solicitudes de incorporación de cambios a la semana ahora entregan cincuenta, cien y, a veces, incluso más; gran parte del código está escrito por agentes de programación, revisado por agentes de revisión de código y fusionado a un ritmo para el que ningún proceso de control de calidad manual fue diseñado. Un equipo con el que hablamos recientemente acababa de completar sus primeras cincuenta solicitudes de incorporación de cambios escritas íntegramente por agentes y nos hizo la pregunta obvia: ¿qué verifica todo esto?
La respuesta tradicional —escribir más scripts de prueba— no resiste ese volumen de solicitudes de incorporación de cambios. Crear y mantener los scripts lleva más tiempo que producir el código escrito por agentes, por lo que la suite se queda atrás desde el primer día y nunca logra ponerse al día.
Esta guía explica la alternativa que creamos en QA.tech: conectar nuestros agentes de control de calidad a tu repositorio para que cada solicitud de incorporación de cambios active pruebas basadas en objetivos que se generan a partir de lo que ha cambiado. Sin código de pruebas, sin selectores y sin cola de mantenimiento. Así se configura y esto es lo que puedes esperar en cada paso.
Paso 1: Deja que el agente aprenda primero sobre tu aplicación
Antes de que la integración con las solicitudes de incorporación de cambios pueda hacer algo útil, el agente necesita conocer tu producto. Cuando conectas QA.tech a tu entorno de pruebas o entorno aislado, realiza un rastreo inicial: explora la aplicación como lo haría una persona meticulosa recién incorporada, siguiendo cada ruta y acción que puede encontrar, y lo organiza en un grafo de conocimiento sobre cómo está estructurado tu producto.
Dos observaciones prácticas derivadas de cientos de incorporaciones. Primero, si tu aplicación requiere iniciar sesión, configura el flujo de inicio de sesión como un caso de prueba previo; el agente lo completa primero y después rastrea todo lo que hay detrás. Segundo, tú controlas la profundidad del rastreo. Un rastreo superficial (de uno o dos pasos de profundidad en cada recorrido del usuario) es rápido y normalmente suficiente para empezar; puedes profundizarlo en los flujos más importantes en lugar de cartografiarlo todo de forma exhaustiva desde el principio.
Este paso es la razón principal por la que funciona la integración con las solicitudes de incorporación de cambios. Como el agente conoce cada rincón de la aplicación, puede razonar sobre lo que podría afectar un cambio determinado; exactamente el criterio que aplica un buen ingeniero de control de calidad al decidir qué debe comprobar antes de una versión.
Paso 2: Conecta el repositorio
La Integración de GitHub solo lleva unos minutos: autoriza la aplicación, elige los repositorios y selecciona cuándo deben ejecutarse las pruebas; normalmente, al crear o actualizar una solicitud de incorporación de cambios. Las solicitudes de fusión de GitLab siguen el mismo patrón. A partir de este momento, las pruebas forman parte de tu canal de integración en lugar de ser una etapa posterior.
solo lleva unos minutos: autoriza la aplicación, elige los repositorios y selecciona cuándo deben ejecutarse las pruebas; normalmente, al crear o actualizar una solicitud de incorporación de cambios. Las solicitudes de fusión de GitLab siguen el mismo patrón. A partir de este momento, las pruebas forman parte de tu canal de integración en lugar de ser una etapa posterior.Paso 3: Abre una solicitud de incorporación de cambios y observa lo que sucede
Cuando se abre una solicitud de incorporación de cambios, el agente lee lo que se ha añadido y modificado, lo contrasta con su grafo de conocimiento y genera los casos de prueba que justifican esos cambios; normalmente, cuatro o cinco para una solicitud rutinaria, y más para los cambios que afectan a flujos compartidos. Después los ejecuta inmediatamente en un navegador real, interactuando visualmente con la compilación actualizada, exactamente como lo haría un usuario.
Esta es la parte que sorprende a los equipos acostumbrados a las suites de scripts activadas por la integración continua: nadie creó esos casos de prueba. Se derivaron del propio cambio, teniendo en cuenta todo lo que el agente ya sabe sobre tu producto. Añade un filtro nuevo al panel de control y el agente prueba el filtro y los flujos del panel en los que está integrado. Nadie tuvo que acordarse de añadir cobertura.
Paso 4: Lee los resultados donde tus ingenieros ya trabajan
El resultado, correcto o incorrecto, aparece en la propia solicitud de incorporación de cambios. En cada ejecución, el agente genera un informe de evaluación: el objetivo, el resultado esperado, lo que sucedió realmente, un vídeo de la ejecución, capturas de pantalla paso a paso y los registros de la consola y de la red subyacentes. Un fallo no es una X roja que haya que analizar a la inversa: es una explicación escrita de lo que el agente esperaba ver y de lo que vio en su lugar.
Como el agente prueba a través de la interfaz, informa de los fallos a nivel de producto: te indicará que el código de descuento ya no se aplica al finalizar la compra, con las pruebas adjuntas. Ese contexto a nivel de producto es exactamente lo que tus ingenieros —o tus agentes de programación— necesitan para localizar y corregir la causa. Los equipos que ejecutan ciclos de desarrollo agéntico envían nuestros informes de evaluación directamente a sus agentes de programación como contexto del fallo que deben solucionar; y, con la Integración de MCP, esos agentes de programación pueden activar las ejecuciones de pruebas por sí mismos mientras trabajan.
Paso 5: Añade la regresión a las pruebas de PR
Las pruebas activadas por una PR verifican el cambio. Los planes de regresión verifican todo lo demás. En QA.tech agrupas los casos de prueba en planes —un conjunto de pruebas rápidas para cada implementación y una regresión completa antes de las versiones principales— y los ejecutas con la frecuencia que mejor se adapte a tu proceso de publicación.
Como las pruebas se ejecutan en paralelo, el tiempo real transcurrido es una fracción de lo que costaría manualmente la misma cobertura. Un plan de regresión completa reciente que ejecutamos abarcaba un volumen de pruebas que ocuparía a un probador manual durante uno o dos días; se completó en unos veinte minutos. Esa diferencia es la que convierte «ejecutar la regresión completa en cada versión» en una política real y no en una aspiración.
Paso 6: Pregunta al agente dónde es insuficiente tu cobertura
Como el grafo de conocimiento asigna cada flujo que descubrió el rastreo, la plataforma conoce la diferencia entre lo que contiene tu producto y lo que cubren tus pruebas. Puedes preguntarlo directamente en el chat: «¿Cuáles son los flujos de mayor valor que no cubrimos actualmente?». El agente responde a partir de su mapa de tu producto y puede generar las pruebas que faltan en ese momento.
Esto invierte la dinámica habitual de la cobertura. En lugar de que la cobertura sea todo lo que se ha acumulado durante años de creación de pruebas impulsada por tickets, se convierte en una pregunta que puedes formular y poner en práctica esa misma tarde.
Cómo se ve esto después de un mes
El patrón que observamos en los equipos es coherente. La primera semana implica cierto intercambio de preguntas y respuestas: el agente hace preguntas, ocasionalmente necesita contexto sobre las particularidades de tu producto y tú corriges su comprensión. Para la segunda semana, las preguntas son poco frecuentes. Para la tercera, prácticamente han desaparecido, porque el grafo de conocimiento ha asimilado cómo funciona tu producto. A partir de ahí, las pruebas se ejecutan al ritmo de tus solicitudes de incorporación y las personas implicadas revisan los resultados en lugar de mantener scripts. Si quieres conocer la secuencia completa de implementación —desde la prueba de concepto hasta retirar tus conjuntos de pruebas heredados—, la hemos publicado como una guía práctica, Adopción de pruebas agénticas: el plan.
Para los equipos que han dado el salto al código escrito por agentes, esto cierra el ciclo que faltaba: generación de código, revisión del código y verificación, todo ejecutándose a la velocidad de las máquinas, mientras tus ingenieros dirigen el sistema en lugar de alimentarlo.
Preguntas frecuentes
¿Cuántos casos de prueba genera QA.tech por solicitud de incorporación?
Una PR habitual produce normalmente entre cuatro y cinco casos de prueba, derivados de lo que ha cambiado. Los cambios más grandes que afectan a flujos compartidos generan más.
¿Las pruebas de PR requieren casos de prueba existentes?
No. El agente genera casos de prueba a partir del cambio y de su conocimiento de tu aplicación. Los equipos que empiezan sin cobertura de pruebas pueden comenzar en el nivel de PR y crear planes de regresión con el tiempo.
¿Qué ocurre cuando cambia la interfaz de usuario en una solicitud de incorporación?
El agente trabaja a partir de objetivos y de la comprensión visual, en lugar de selectores, por lo que completa la prueba contra la nueva interfaz y solo señala un fallo cuando el comportamiento en sí es incorrecto.
¿Qué configuraciones de CI/CD admite la integración de PR de QA.tech?
Las solicitudes de incorporación de GitHub y las solicitudes de fusión de GitLab son los principales puntos de integración, y los resultados se notifican de vuelta en la PR como una comprobación.
Descubre lo que los agentes de QA generan para tu próxima solicitud de incorporación: conecta un repositorio en QA.tech y ejecuta la primera prueba en cuestión de minutos.
