Lo que serás capaz de hacer
- Escribir criterios de aceptación observables y congelarlos antes de que empiece la construcción.
- Convertir cada criterio en un recorrido con condiciones previas y pasos observables.
- Preparar y demostrar el entorno de pruebas en un paso aparte, antes de que entre el probador.
- Ejecutar los recorridos con Playwright MCP y leer el informe por sus veredictos.
- Montar un ciclo de corrección y nueva ejecución en el que nadie certifica su propia corrección.
Ideas clave
- En las pruebas de aceptación con agentes, un agente de IA ejecuta cada recorrido de usuario contra la aplicación en marcha y emite un veredicto por cada criterio de aceptación congelado.
- Congela los criterios antes de que exista el código y dale a cada uno exactamente un recorrido que lo cite palabra por palabra.
- El agente que prueba nunca corrige: un fallo vuelve a la construcción, y solo una nueva ejecución completa cuenta como prueba.
- BLOCKED es un veredicto, no un hueco que esconder; léelo antes que FAIL.
- Esta capa no sustituye a la CI; detecta los defectos que viven entre capas que pasaron cada una por su cuenta.
Qué hacen aquí las pruebas de aceptación con Playwright MCP
Las pruebas de aceptación con agentes son un ciclo de verificación en el que un agente de IA ejecuta cada recorrido de usuario en un navegador real e informa de si pasa o falla frente a criterios de aceptación congelados. Los recorridos de API y de MCP funcionan igual, como llamadas reales contra la aplicación en marcha.
Las pruebas que escribe para sí mismo quien construye no demuestran nada. Queremos el veredicto de un agente que solo lee los criterios y maneja el producto. Cuando Claude Code construye una funcionalidad, un segundo agente ejecuta cada recorrido con Playwright MCP y hace una captura de cada observación decisiva. ConvOps ejecuta los pasos, los puntos de control y el ciclo de corrección. Es uno de los ciclos con los que dirigimos nuestra empresa.
Todos los ejemplos usan Quillbay, una aplicación ficticia de reservas de clases para talleres de cerámica, y su nueva lista de espera para clases completas.
| No es | Porque |
|---|---|
| Pruebas de aceptación de usuario (UAT) | Allí dan el visto bueno los usuarios de negocio; aquí un agente verifica criterios ya aprobados |
| Probar un agente de IA | El agente es quien prueba, no lo que se prueba |
| Criterios convertidos en código de prueba | Eso acaba en un archivo .spec.ts. Esto acaba en un veredicto por recorrido, con evidencias |
| Parte | Qué es |
|---|---|
| Disparador | Terminan los pasos de construcción de un plan. Sin calendario |
| Entradas | Criterios de aceptación congelados, el plan de recorridos y la aplicación en marcha en el entorno de su propia rama |
| Salidas | Un informe con un veredicto por recorrido, capturas y una recomendación: PROCEED o FIX REQUIRED |
Por qué lo creamos: capas en verde, recorridos rotos
Las pruebas unitarias en verde te dicen que las piezas funcionan. No dicen nada sobre si una persona puede terminar la tarea en pantalla.
Antes de este ciclo, todas las capas inferiores pasaban: pruebas unitarias, revisiones de fase y la suite de regresión del pipeline de merge. Aun así, la primera ejecución de los recorridos con agentes contra la aplicación real falló en una gran parte de ellos. Los defectos vivían entre capas: un enlace que construía un servicio y leía otro, una redirección que perdía un parámetro. Ninguna capa era dueña de esa costura, así que ninguna la detectó.
De ahí salieron dos convicciones. Quien construye no puede ser juez, así que quien prueba nunca escribe ni corrige código. Y solo una ejecución contra la aplicación real demuestra un criterio.
Si las funcionalidades de tus agentes pasan todas las comprobaciones y aun así se rompen en pantalla, descubre cómo ConvOps lleva un plan desde los criterios congelados hasta una build verificada(se abre en una pestaña nueva).
Cómo funciona: seis pasos y cuatro agentes
El orden de los pasos es la garantía. Los criterios se congelan antes de que exista código, el entorno se demuestra antes de que llegue quien prueba y la decisión la toma alguien que no escribió la corrección.
| # | Paso | Quién lo ejecuta | Punto de control |
|---|---|---|---|
| 1 | Escribir los criterios | Se redactan con el plan y los aprueba una persona | La aprobación congela la lista |
| 2 | Planificar los recorridos | Planificador de pruebas | Ninguno |
| 3 | Preparar el entorno | Agente de infraestructura | Solo en verde; después aprueba una persona |
| 4 | Ejecutar los recorridos | Probador de aceptación | Una persona aprueba el informe |
| 5 | Decidir | Paso de decisión | Pasa, o falla y va a la corrección |
| 6 | Corregir los fallos | Agente desarrollador | Ninguno |
Claude Code construye la funcionalidad entre los pasos 2 y 3.
Escribir los criterios. Cada uno nombra un actor, un comportamiento y algo que se pueda observar: una pantalla, un mensaje, una respuesta. «Existe el código» nunca es un criterio, porque lo que no se puede observar no se puede aceptar. La aprobación congela la lista: los pasos posteriores nunca añaden, quitan ni reinterpretan ninguno.
Planificar los recorridos. Un recorrido por criterio, citado palabra por palabra y con su id, para que cada criterio tenga exactamente un lugar donde se demuestra.
Preparar el entorno. Un agente de infraestructura dedicado levanta el entorno de la rama del propio plan, aprovisiona datos y credenciales con el mecanismo del plan y los deja registrados. El punto de control exige verde, no esfuerzo. Quien prueba no prepara nada, así que no puede aprobar fabricándose un caso fácil.
Ejecutar, decidir, corregir. El probador de aceptación ejecuta los recorridos y nunca corrige. Un fallo envía el informe al agente desarrollador, que hace commit de las correcciones en la misma rama, y el plan entero vuelve a ejecutarse.
El ciclo no tiene temporizador: se ejecuta tras la construcción de cada plan y, en una tarea, siempre que cambia un recorrido. En una tarea, la ejecución genera entre 3 y 8 recorridos: el camino feliz más la ruta de error de mayor riesgo por cada comportamiento modificado. Solo se puede omitir cuando no hay ningún recorrido que ejecutar (una refactorización pura, herramientas, documentación, configuración o cambios solo de pruebas), y siempre indicando el motivo. Ante la duda, se ejecuta.
Los Playwright Test Agents(se abre en una pestaña nueva) de Microsoft (planner, generator, healer) generan y reparan código de prueba. Los nuestros producen un plan a partir de requisitos congelados y un informe de veredictos. Los puntos de control funcionan como en cómo construimos un sistema de IA que se mejora solo, y las aprobaciones son puntos de control con una persona en el ciclo.
Una ejecución paso a paso: la lista de espera de Quillbay
Lo interesante no es el primer FAIL. Es la nueva ejecución tras la corrección, porque el paso de decisión no acepta ninguna otra prueba.
Disparador. Terminan los pasos de construcción de plan/waitlist. Los criterios FR-1 a FR-4 se congelaron antes de que existiera código.
El plan. El recorrido U2 cita FR-2 y lo reproduce: «Cuando se libera una plaza, el primer alumno de la lista recibe un correo cuyo enlace abre la clase con la plaza reservada durante 2 horas». Cada condición previa indica cómo confirmarla: la clase acc-wl-r7-class-wheel-basics está completa con 8 de 8 y la página muestra «Full» (completa) y el botón «Join waitlist» (apuntarse a la lista de espera); los dos alumnos pueden iniciar sesión, y el correo saliente llega a la bandeja de captura.
Preparar. El agente de infraestructura demuestra que wl-waitlist.app.quillbay.example.com y su API están en verde, y registra las fixtures de los alumnos y la clave del propietario del taller para reutilizarlas.
Ejecución 1. El probador de aceptación ejecuta cuatro recorridos a 1440x900 y vuelve a comprobar las pantallas con maquetación a 390x844.
| Recorrido | Veredicto | Qué vio |
|---|---|---|
| U1 | PASS | «You are #1 on the waitlist» (eres el n.º 1 de la lista de espera) |
| U2 | FAIL | El enlace del correo abre «Class not found» (clase no encontrada): lleva el id de la entrada de la lista de espera, no el id de la clase |
| U3 | BLOCKED | Falta P3: no hay captura de correo en el entorno de la rama, y la cabecera lo indica |
| A1 | PASS | GET /v1/classes/{id}/waitlist como propietario devuelve 200 con el alumno A en la posición 1 |
Recomendación: FIX REQUIRED. U2 es una costura: la API y la aplicación pasan cada una sus pruebas unitarias, y solo el recorrido cruza ambas.
Decidir. Una persona aprueba el informe y la decisión es suspenso. U2 es código que entregó este plan, así que se corrige en la rama; no se abre como ticket.
Corregir. El agente desarrollador reproduce U2 en el mismo entorno, cambia el enlace, ejecuta la prueba unitaria del archivo modificado y hace commit de fix(waitlist): email link uses the class id (4c1e9a7) en plan/waitlist. El agente de infraestructura configura la captura de correo.
Ejecución 2. El plan entero vuelve a ejecutarse: los cuatro recorridos, no solo U2 y U3. Todos pasan, y la captura de U2 muestra «Seat held for you for 2 hours» (plaza reservada para ti durante 2 horas). Recomendación: PROCEED. La decisión es aprobado, y el informe alimenta la sección de verificación de la merge request.
Cómo es el informe y cómo leerlo
Lee BLOCKED antes que FAIL. Un recorrido que nadie pudo ejecutar es el que más probabilidades tiene de esconder un defecto real.
| Parte | Qué contiene |
|---|---|
| Cabecera | Ejecución, ejecución anterior con recuentos, rama y head, hosts, viewports, veredicto |
| Declaraciones obligatorias de cabecera | Todo lo que la ejecución no pudo probar, cada cosa con su nombre. Ejecución 1: «P3: captura de correo sin configurar; U2 y U3 dependen de ella» |
| Resultados por recorrido | Una fila por recorrido, la ejecución anterior junto a la actual, imágenes como evidencia |
| Fallos en detalle | Paso, resultado esperado, resultado real, evidencia, corrección recomendada |
| Lista de regresión | Reservar una clase que no está completa sigue funcionando. Cancelar una reserva sigue liberando la plaza |
| Recomendación | PROCEED o FIX REQUIRED |
| Veredicto | Significado |
|---|---|
| PASS | Cada paso se observó tal como lo indica el criterio |
| PARTIAL PASS | El recorrido funciona, pero una de las observaciones indicadas no se cumple del todo |
| FAIL | El resultado real de un paso difiere del esperado |
| BLOCKED | No se pudo ejecutar el recorrido; se nombra lo que faltaba |
| COVERED BY SUITE | Lo demuestra una prueba de regresión automatizada que el informe cita; no se vuelve a ejecutar |
Nuestros planes fijan una regla más: un paso que necesitó un requisito previo no documentado, un reintento o un arreglo manual es un FAIL, aunque el comportamiento acabara funcionando. Un aprobado que necesitó ayuda no le funcionará a un usuario real. Y un PASS cuya captura no muestra el elemento comprobado no es evidencia: quien acepta el veredicto abre las imágenes.
Qué falla: costuras de las que ninguna capa se ocupaba
La mayoría de nuestros fallos de aceptación no eran bugs que se le escaparan al modelo. Eran costuras entre capas de las que ninguna capa se ocupaba.
La principal tiene la forma del U2 de Quillbay: una primera ejecución de aceptación falla en una gran parte de los recorridos mientras todas las capas inferiores están en verde, y cada defecto está entre capas. La regla que nos dejó: ejecuta la aceptación en un entorno real antes de que los pasos de revisión dejen de ser baratos, y reserva una segunda ejecución completa para cualquier plan con superficie de UI, API y MCP.
| Fallo | Regla que nos dejó |
|---|---|
| Las rondas de corrección introducían regresiones que detectaba la siguiente ejecución. En Quillbay, una corrección de U2 que de paso ordenara la página de la clase rompería U1 | Corrige solo los fallos reportados, sin retoques. La nueva ejecución completa detecta lo que haya roto una corrección, y una persona decide cuándo dejar de iterar |
| Dos sesiones compartían un mismo navegador de Playwright MCP. Otra sesión navegó en la pestaña a mitad de recorrido y el estado observado desapareció | Cada sesión maneja su propio contexto de navegador o un script independiente de Playwright, vuelve a localizar su página en cada llamada y comprueba la URL antes de leer |
| Un recorrido pasó en el servidor de desarrollo y mostró contenido obsoleto una vez compilado | Los recorridos que dependen del prerenderizado o del modo de caché se ejecutan sobre una imagen compilada o un entorno desplegado: un servidor de desarrollo renderiza cada petición desde cero |
| Una configuración ausente dejó un recorrido en BLOCKED durante varias ejecuciones y escondió detrás otro defecto distinto | BLOCKED es un veredicto que nombra en la cabecera lo que falta. La ejecución nunca finge un aprobado |
| Un plan contenía comprobaciones que el entorno nunca podría cumplir: una regla ya rota en main, un inicio de sesión que el entorno no tenía | El planificador de pruebas contrasta cada recorrido con lo que el entorno puede hacer realmente |
Separar encontrar y corregir en dos trabajos distintos es también la columna vertebral de nuestro ciclo de web que se repara sola.
Monta el tuyo: las instrucciones que recibe cada agente
Empieza por los criterios y la regla de «nunca corregir». Playwright MCP es la parte fácil. El probador sirve para verificar, no para investigar: depura primero y ejecuta la aceptación cuando creas que la build funciona. Los pasos de arriba marcan el orden; estas son las instrucciones, listas para copiar.
Planificador de pruebas: la plantilla de recorrido.
Para cada criterio congelado, escribe UN recorrido:
ID: U<n> (UI) o A<n> (API/MCP)
Criterio: <FR id>, citado palabra por palabra
Condiciones previas: cada una con «Cómo confirmarla».
Si falta una, es un bloqueo, no algo que sortear.
Pasos: numerados; cada uno indica qué vas a observar.
Viewports: 1440x900; vuelve a comprobar cada pantalla
con maquetación a 390x844.
Fixtures: prefijo acc-<plan>-<run>-; límpialas tras la ejecución.
Contrasta cada recorrido con lo que el entorno
puede hacer realmente.
Agente de infraestructura: preparar y verificar.
Prepara el entorno de la rama del plan y demuestra que está en verde.
1. Arranca todos los servicios que toca el plan. Todos deben estar activos.
2. Aprovisiona datos y credenciales SOLO con el mecanismo
del plan. Si no hay mecanismo: detente y pregunta. Registra
las credenciales para el probador.
3. Verifica:
- health devuelve 200
- un endpoint de datos REAL devuelve 2xx, no solo health
- llamada sin autenticar: 401/403; autenticada: 2xx
(MCP: tools/list Y una llamada autenticada a una herramienta)
- 3-5 páginas clave con Playwright: sin errores de consola,
sin peticiones fallidas, sin pantallas en blanco
- el flujo principal funciona de principio a fin una vez
4. Arregla lo que esté en rojo, vuelve a verificar y avanza solo en verde.
Informa de los defectos del producto con ubicación y evidencias.
No ejecutes los recorridos. No desmontes nada.
Probador de aceptación: ejecutar e informar.
El entorno está preparado y en marcha. Reutiliza las credenciales
registradas. No arranques ni desmontes nada.
Ejecuta cada recorrido de UI con Playwright MCP y cada recorrido
de API/MCP con llamadas reales; después, la lista de regresión.
Sigue el plan en orden. Nunca corrijas código. Nunca omitas un
fallo. Nada de pruebas improvisadas.
Haz una captura de cada observación que decide un paso.
Registra los cuerpos de las respuestas de la API.
Veredicto por recorrido: PASS, PARTIAL PASS, FAIL, BLOCKED,
COVERED BY SUITE.
Informe: Cabecera; Declaraciones obligatorias de cabecera (lo que
no pudiste probar, cada cosa con su nombre); Resultados por
recorrido; Fallos en detalle (paso, esperado, real, evidencia,
corrección recomendada); Lista de regresión; Recomendación:
PROCEED o FIX REQUIRED.
Regla de decisión.
PASS solo cuando cada recorrido es PASS o una excepción
aceptada: un fallo en código que este cambio no entregó,
registrado como su propio ticket y citado por id.
Cualquier otra cosa es FAIL: envía el informe a la corrección
y vuelve a ejecutar el plan ENTERO.
Un fallo en código que este cambio entregó se corrige en la
rama; nunca se registra como ticket aparte.
¿No está claro si un comportamiento es intencionado? Decide una persona.
Agente desarrollador: corregir.
Para cada recorrido fallido: reprodúcelo en el mismo
entorno, encuentra la causa, corrígela y vuelve a ejecutar
el recorrido en vivo.
Corrige solo lo que exigen los fallos. Nada de detalles ni retoques.
Ejecuta las comprobaciones unitarias y de lint solo de los
archivos modificados.
Haz commit en la misma rama. Registra qué cambió y por qué.
Nunca certifiques tu propia corrección: la nueva ejecución es la prueba.
Esta capa no sustituye a la CI: las pruebas unitarias, de integración y de regresión siguen siendo el punto de control determinista del pipeline de merge.
Pasos
Escribe criterios observables y congélalos
Dale a cada criterio un actor, un comportamiento y algo que se pueda observar en pantalla o en una respuesta. La aprobación de una persona congela la lista; un cambio de alcance vuelve a este paso.
Escribe un recorrido por criterio
Cita el criterio palabra por palabra, indica su id, enumera las condiciones previas con cómo confirmar cada una y describe una observación para cada paso.
Prepara el entorno en un paso propio
Un agente de infraestructura aprovisiona datos y credenciales con el mecanismo del plan y demuestra que el endpoint de health, un endpoint de datos real, la autenticación en ambos sentidos y las páginas clave están en verde antes de que nadie pruebe.
Ejecuta los recorridos con un probador independiente
Dale al probador de aceptación Playwright MCP en su propio contexto de navegador, llamadas reales para los recorridos de API y dos reglas: nunca corregir, nunca omitir.
Lee el informe y decide
Lee primero las filas BLOCKED. Aprueba solo cuando cada recorrido sea PASS o una excepción aceptada que se gestiona como su propio ticket.
Corrige en la rama y vuelve a ejecutarlo todo
El agente desarrollador corrige solo los fallos reportados y hace commit en la misma rama. El plan entero vuelve a ejecutarse; nadie certifica su propia corrección.
Preguntas frecuentes
¿Qué son las pruebas de aceptación con agentes?
Las pruebas de aceptación con agentes son un ciclo de verificación en el que un agente de IA ejecuta cada recorrido de usuario en un navegador real e informa de si pasa o falla frente a criterios de aceptación congelados. ConvOps lo ejecuta como pasos de un flujo de trabajo: una persona congela los criterios, un planificador de pruebas escribe un recorrido por criterio, un probador de aceptación independiente los ejecuta con Playwright MCP y cualquier fallo se corrige en la rama antes de que el plan entero vuelva a ejecutarse.
¿Para quién son las pruebas de aceptación con agentes?
Las pruebas de aceptación con agentes son para responsables de ingeniería y fundadores que lanzan funcionalidades con agentes de programación como Claude Code. ConvOps las ejecuta tras la construcción de cada plan, de modo que cada criterio que aprobó una persona queda demostrado en la aplicación en marcha, con una captura por cada observación decisiva, antes de que se revise la merge request.
¿Se pueden usar agentes de IA en las pruebas de QA?
Sí, como capa de recorridos. En ConvOps, un agente probador de aceptación ejecuta cada recorrido de usuario con Playwright MCP y cada recorrido de API con llamadas reales, y después emite un veredicto por recorrido con evidencias. Nunca corrige código y nunca omite un fallo. La suite de regresión de la CI sigue siendo el punto de control determinista, y una persona lee el informe antes de la decisión.
¿Es fiable Playwright MCP para las pruebas de aceptación?
Sí, como vehículo, con dos condiciones. ConvOps demuestra que el entorno está en verde antes de que llegue el probador, y cada sesión maneja su propio contexto de navegador, vuelve a localizar su página en cada llamada y comprueba la URL antes de leer. Un navegador compartido pierde el estado cuando otra sesión navega en la pestaña. Cada observación decisiva lleva una captura que muestra el elemento comprobado.
¿Cómo hago que un agente de programación con IA pruebe su propio código en un navegador real?
Añade el servidor MCP de ConvOps en https://mcp.convops.app/ a tu cliente de IA e inicia sesión una vez. Después, escribe criterios de aceptación observables y congélalos, haz que un planificador de pruebas escriba un recorrido por criterio y dale Playwright MCP a un segundo agente para que los ejecute. Quien construye nunca evalúa su propio trabajo: los fallos se corrigen en la rama y el plan entero vuelve a ejecutarse.
¿Las pruebas de aceptación con agentes sustituyen a las UAT con personas?
No. En ConvOps, el agente verifica frente a criterios que una persona aprobó antes de la construcción, y una persona lee y aprueba cada informe. Un hallazgo en el que nadie sabe si el comportamiento es intencionado pasa a una persona antes de decidir si pasa o falla. El agente se pronuncia sobre lo que observó, nunca sobre la intención.
¿Las pruebas de aceptación con un agente de IA sustituyen a las pruebas de CI?
No. En los planes de ConvOps, las pruebas unitarias, las de integración y la suite de regresión se ejecutan en el pipeline de merge como punto de control determinista. La aceptación con agentes es una cuarta capa: ejecuta recorridos sobre la aplicación en marcha y detecta defectos que viven entre capas que pasaron cada una por su cuenta. No decide el merge por sí sola.
¿Qué pasa cuando el agente no puede probar un recorrido?
El recorrido queda en BLOCKED, y la cabecera del informe nombra lo que falta, por ejemplo una bandeja de captura de correo que el entorno no tenía. ConvOps nunca cuenta BLOCKED como aprobado. El agente de infraestructura aporta lo que faltaba y el plan entero vuelve a ejecutarse. Lee primero las filas BLOCKED: un recorrido que nadie pudo ejecutar puede esconder un defecto real.