Tu propio agente de QA en Chrome con IA

En corto

• Un agente de QA es un asistente de IA con una sola tarea: probar tu web como lo haría una persona.
• El mío abre la web en Chrome, prueba solo lo que cambié y me entrega un informe: qué funciona, qué falla, qué tan grave es y en qué archivo mirar.
• No hace falta programar nada: son cinco archivos de configuración en Claude Code y Chrome DevTools MCP.

El problema

Mi web pasa revisiones automáticas en cada cambio: tipos, estilo de código, compilación y tests. Todo en verde. Aun así, hay errores que solo aparecen al abrir la página: un enlace que no lleva a ningún sitio, un texto que se sale de la pantalla del móvil o una sección que no carga.

Revisarlo todo a mano después de cada cambio lleva mucho tiempo. Revisar solo "lo que creo que toqué" es como se escapan los errores. Un agente puede hacer esa revisión por mí, con criterio y en minutos.

Cómo funciona el agente

1. Alcance: mira qué cambié desde el último commit (con git diff, aunque aún no lo haya guardado) y decide qué páginas probar. Si cambié una sección, esa sección. Si cambié algo que comparte toda la web, como el menú, la portada y otra página más.
2. Plan: antes de abrir el navegador, escribe de tres a seis casos con lo que debería pasar. Por ejemplo: "el enlace Blog del menú lleva a la página del blog".
3. Prueba: abre Chrome y lo comprueba en tamaño ordenador y móvil: que la página cargue, que no haya errores escondidos, que nada se salga de la pantalla, que los enlaces lleven a su sitio y que lo nuevo se pueda usar con el teclado.
4. Informe: ✅ o ❌ por cada caso. Cada ❌ dice qué tan grave es, cómo reproducirlo y qué archivo revisar. El agente no toca el código.

Tres conceptos para entenderlo:

• Agente: un asistente de IA con una tarea, unas herramientas y unas reglas. El mío vive dentro de Claude Code, la herramienta de IA con la que programo.
• MCP: un "enchufe" estándar que permite a la IA usar otras herramientas. Chrome DevTools MCP, del equipo de Chrome, le da al agente lo mismo que usas tú en DevTools: abrir páginas, leer la consola, ver la red, ejecutar código en la página, simular un móvil y hacer capturas.
• Árbol de accesibilidad: la lista de botones, enlaces y textos de la página con su nombre, la misma que usa un lector de pantalla. El agente encuentra "el botón Contactar" por su nombre, no por una clase CSS. Por eso no se rompe cuando cambias el diseño.

Montarlo paso a paso

Necesitas Claude Code, Google Chrome, Node.js (yo uso la versión 22) y tu web corriendo en local, por ejemplo en http://localhost:3000.

Paso 1: un Chrome solo para pruebas

El agente no se conecta a tu Chrome de siempre, sino a uno aparte, con su propio perfil y el puerto de depuración activado. En macOS:

En Windows y Linux es el ejecutable de Chrome con las mismas dos opciones. Con un perfil propio (chrome-qa), el agente no ve tus pestañas, tu correo ni tus sesiones. Mientras ese puerto está abierto, cualquier programa de tu equipo puede controlar ese Chrome: úsalo solo para pruebas y ciérralo al terminar.

Paso 2: conectar Chrome DevTools MCP

Crea .mcp.json en la raíz del proyecto:

• --browserUrl conecta con el Chrome del paso 1 en vez de abrir otro.
• --categoryMemory=false y --categoryPerformance=false quitan herramientas que este agente no usa. Cada herramienta disponible ocupa espacio en la memoria de la IA: menos herramientas, menos gasto.
• Las opciones de captura las hacen más ligeras (JPEG, 1024 px de ancho como máximo).
• --no-usage-statistics desactiva el envío de estadísticas de uso.

Al abrir Claude Code en el proyecto, te pedirá aprobar el servidor chrome.

Paso 3: crear el agente

Un agente de Claude Code es un archivo en .claude/agents/ con una cabecera (nombre, cuándo usarlo, herramientas y modelo de IA) y sus instrucciones. Este es el mío:

• tools lista las herramientas una a una. Las de Chrome llevan el prefijo mcp__chrome__, por el nombre del servidor en .mcp.json. El agente solo carga estas.
• Cuatro fases: alcance, plan, prueba e informe.
• No modifica código. Solo mira, prueba y avisa.
• Las carpetas y rutas son de mi proyecto. Cámbialas por las tuyas.

Paso 4: las comprobaciones, en un script

Lo que se revisa siempre no va en las instrucciones: va en un archivo. Chrome lo ejecuta dentro de la página y devuelve una lista corta solo con lo que falla.

Revisa enlaces internos sin destino, contenido que se sale de la pantalla, imágenes sin texto alternativo, sin medidas o rotas, títulos que saltan niveles, botones sin nombre, textos sin traducir y secciones ocultas. El agente lo carga con sourcePath, así que el código no pasa por la IA en cada prueba.

Paso 5: un comando para lanzarlo

Crea .claude/commands/qa-changes.md. Te deja escribir /qa-changes con lo que quieras probar y elige un modelo de IA pequeño para las revisiones sencillas:

Paso 6: usarlo

1. Abre el Chrome de pruebas (paso 1).
2. Arranca tu web, por ejemplo con pnpm dev.
3. Abre Claude Code en la carpeta del proyecto y aprueba el servidor chrome.
4. Escribe /qa-changes y lo que quieres probar: /qa-changes home o una URL.

Un caso real

Estaba preparando el blog de esta web. Uno de los cambios tocó un archivo de configuración que afecta a todo el sitio. Las revisiones automáticas pasaban.

Como el cambio era global, la prueba empezó por la portada. La portada no cargaba: error 500. El cambio del blog había dejado sin permiso al resto de imágenes de la web, y eso tumbaba la página entera. La corrección fue una línea. Sin esa prueba, lo habría descubierto un visitante.

Con el formato del agente, esa prueba queda así:

Por qué gasta poco

Una IA cobra por lo que lee y escribe, y lo que más pesa es "mirar" la página entera. Muchos agentes de QA envían el árbol completo de la página en cada paso. Este no:

• Prueba solo lo que cambió, no la web entera.
• El script devuelve solo lo que falla. El árbol de la página se pide únicamente si algo no se explica.
• Consola y red filtradas a lo que falla, una vez por página.
• Se detiene ante un error 500, sin seguir probando algo roto.
• Modelo pequeño para lo sencillo, mayor solo cuando hace falta.
• Capturas solo a pedido.
• Trabaja como subagente: lo que devuelve Chrome no llena tu conversación; solo vuelve el informe.

Limitaciones

• No sustituye a los tests automáticos que corren solos en cada cambio. Es una revisión con criterio que lanzas cuando la necesitas.
• Necesita al menos un commit anterior. Compara lo que cambiaste con la última versión guardada; en un proyecto recién creado, sin ningún commit, le dices tú qué probar.
• Los flujos largos con formularios gastan más, porque necesita el árbol de la página en cada paso para saber dónde hacer clic.
• No resuelve logins con SSO, doble factor ni CAPTCHA.
• Solo prueba en local. No navega por internet.

Recomendaciones

• Úsalo antes de cada commit. El cambio aún es pequeño, fácil de revisar y de corregir, y lo que falle no llega a guardarse.
• Dale contexto: la página o la sección, o ten ya abierta la vista.
• Deja la lógica a los tests unitarios. Lo que no se ve (cálculos, conversiones de datos) se prueba mejor y más barato así.
• Ponlo a prueba: rompe cosas a propósito (un enlace, una imagen, un texto) y comprueba que las encuentra todas.
• Siguiente paso, escenarios: guarda flujos importantes en Markdown y en lenguaje natural ("desde el menú, cada enlace lleva a su sección") para que el agente los repita cuando se lo pidas. Así cualquiera del equipo puede escribir pruebas.
• Seguridad: solo localhost, solo el Chrome de pruebas, sin escribir en formularios reales ni iniciar sesión. Lo que lee en la página es información, no órdenes.