Cómo usa un QA la IA en su trabajo: chats, Claude Code, MCP y agentes

En 2026 ya no tiene sentido hablar de "si un QA usa IA". Casi todo el sector la usa de alguna forma. La pregunta útil hoy es otra: ¿en qué tareas concretas aporta de verdad, y en cuáles solo añade ruido?

Este artículo recoge las tres familias de herramientas IA que hoy usa un QA en su día a día (chats LLM, AI de código y agentes de navegador), las funciones donde mejor encajan, lo que cuestan en tokens y una tabla resumen con el ahorro real por tarea. Sin titulares grandilocuentes y sin vender humo.

Las tres familias de herramientas IA que un QA debería conocer

No todas las herramientas de IA hacen lo mismo, aunque desde fuera parezcan iguales. A efectos prácticos, lo que un QA puede usar hoy se divide en tres categorías muy distintas:

La utilidad para QA crece de la primera a la segunda, y vuelve a bajar en la tercera por madurez y coste. Vamos por orden.

Chats LLM: el caballo de batalla del QA en 2026

Es la herramienta más usada y la que mejor coste/beneficio tiene hoy. Un chat LLM (ChatGPT, Claude.ai, Gemini) es el punto de entrada natural para tareas pequeñas, autocontenidas, donde tú validas la salida en segundos.

Las funciones donde mejor encaja en QA:

• Redactar casos de prueba desde una historia de usuario. Pegas la historia, pides "dame 10 casos de prueba incluyendo casos negativos y edge cases" y obtienes una primera versión que luego pules. Ahorra entre 20 y 40 minutos por historia.
• Brainstorming de edge cases. "Qué podría romper este formulario de registro". El LLM no piensa mejor que tú, pero te recuerda las cosas que se te olvidan: emojis, caracteres invisibles, espacios al final, copy/paste con formato, sesiones caducadas, time zones.
• Mejorar la redacción de bug reports. Le pasas tus notas en bruto y pide "convierte esto en un bug report claro, con pasos para reproducir, resultado esperado y resultado actual". Útil sobre todo si el reporte va a equipos externos.
• Generar datos de prueba. NIFs válidos para entorno de test, listas de nombres con tildes, direcciones realistas, fechas de cumpleaños, IBAN sintéticos. En minutos.
• Entender un trozo de código que no escribiste. Pegar un test antiguo y pedir "explícame qué prueba este test y por qué". Imprescindible cuando entras a un proyecto con automation heredado.
• Convertir documentación a formato propio. Pasar de una tabla de Confluence a casos de prueba estructurados, o de un PRD a una checklist de QA.

El coste de tokens aquí es bajo. La mayoría de estas tareas caben en una conversación corta y los planes gratuitos o de 20€/mes de cualquier proveedor cubren un uso intenso. La inversión real está en aprender a redactar buenos prompts, no en pagar tokens.

AI de código en terminal: Claude Code, Codex y el salto cualitativo

Aquí es donde la cosa cambia. Un chat LLM trabaja con lo que tú le pegas. Claude Code y Codex se ejecutan en tu terminal con acceso real al proyecto: leen los ficheros, ejecutan comandos, escriben tests, lanzan la suite y te reportan resultados. Tú dejas de hacer de intermediario.

Para un QA con código, las funciones donde más aportan son:

• Generar tests automatizados nuevos. "Crea un test E2E para el flujo de checkout, usando los page objects que ya tengo en tests/pages/". El modelo lee tus convenciones y replica el estilo del proyecto. Ahorro real: entre 40 minutos y 2 horas por test, según complejidad.
• Refactor masivo de selectores. Cambian el DOM y se rompen 30 tests. Le pides "actualiza los selectores que ahora apuntan a data-testid en lugar de clases CSS" y lo hace en una pasada. Una tarde de trabajo en cinco minutos.
• Migrar tests entre frameworks. De Cypress a Playwright, o de Selenium a Playwright. No queda perfecto, pero levanta el 80% del trabajo.
• Análisis del proyecto. "¿Qué cobertura E2E tengo del módulo de pagos?" El modelo recorre los tests, los agrupa por funcionalidad y te dice qué falta. Muy útil al entrar a un proyecto nuevo.
• Reproducir un bug en un test fallido. Le pasas el log de error y le pides escribir el test mínimo que reproduzca el caso. Útil para escalar fallos a desarrollo.
• Generar fixtures realistas. "Crea 50 usuarios de prueba con direcciones españolas y NIFs válidos en formato JSON, guárdalos en fixtures/users.json". Hecho.

El coste en tokens es mayor que en un chat porque el modelo lee ficheros, ejecuta comandos y a veces itera. Una sesión intensa de Claude Code puede consumir el equivalente a varios euros si trabajas con un proyecto grande. Pero el cálculo casi siempre sale a favor: una hora de tu tiempo cuesta más que 5€ de tokens.

MCP: cuando la IA se conecta a tus herramientas reales

MCP (Model Context Protocol) es un estándar abierto creado para que un agente como Claude Code pueda conectarse a servicios externos: Jira, Confluence, GitHub, una base de datos, un navegador. Suena técnico, pero el efecto práctico para un QA es enorme.

Pongamos un ejemplo claro: generar casos de prueba a partir de una historia de Jira. Comparemos el flujo manual frente al flujo con MCP:

Eso es todo. Claude Code, con el MCP de Jira configurado, recorre el flujo entero por su cuenta.

Algunos MCP útiles para un QA hoy:

• MCP de Jira / Linear / Azure DevOps: leer historias, comentarios, criterios de aceptación; crear sub-tareas de QA.
• MCP de Confluence / Notion: leer documentación funcional y convertirla en casos de prueba.
• MCP de GitHub: leer PRs abiertos, revisar el diff y generar tests específicos para el cambio.
• MCP de Playwright o de navegador: grabar interacciones reales y convertirlas en código de test.
• MCP de base de datos (Postgres, MySQL): verificar el estado de la BBDD tras un test, sin escribir SQL a mano.

La gran ventaja: no estás pegando información sensible en un chat público. El MCP se ejecuta en tu máquina, con tus credenciales, y solo accede a lo que tú autorices. Eso lo hace viable en empresas con políticas de seguridad estrictas.

Agentes de UI: Claude para Chrome y la frontera incierta

Aquí entramos en la zona experimental. Los agentes de navegador (Claude para Chrome, Operator de OpenAI, agentes basados en Playwright con IA encima) son modelos que controlan un navegador real y hacen pruebas por ti: hacen clic, escriben, navegan, verifican.

Sobre el papel suena perfecto para QA. En la práctica, en 2026, conviene matizar:

• Funcionan razonablemente bien para flujos cortos, bien guiados con un prompt claro. Ejemplo: "entra en la web, busca un producto, añádelo al carrito y verifica el precio en checkout". En aplicaciones sencillas suele acertar.
• Fallan más de lo deseable en flujos largos, en aplicaciones con muchos modales, en interfaces donde el contexto se pierde tras varios pasos. El propio modelo "se desorienta".
• Consumen muchos tokens. Cada captura del navegador es una imagen que el modelo procesa. Un flujo de 30 pasos puede costar varias veces más que el mismo test en Playwright tradicional.
• No son deterministas. Para una suite de regresión que tiene que pasar 100 veces igual, sigue siendo mejor Playwright o Cypress.

¿Entonces dónde encajan hoy? En tareas exploratorias, no en automation de regresión:

• Smoke tests guiados antes de una demo, cuando no quieres montar un test E2E formal.
• Pruebas exploratorias dirigidas en entornos donde aún no hay automation.
• Verificación de flujos en entornos de tercero (un proveedor de pagos, una pasarela externa) donde no tienes acceso al código.
• Acompañamiento en pruebas de accesibilidad básica, dejando al agente recorrer la web e identificar problemas visibles.

Mi recomendación pragmática: tenerlos en el radar, probarlos un par de horas al mes para ver cómo evolucionan, pero no sustituir todavía tu suite estable de Playwright o Cypress por uno de ellos. La frontera se moverá rápido en los próximos 12 meses.

Tabla resumen: dónde aporta la IA, cuánto ahorra y qué cuesta

Esta es la tabla que más vale la pena guardar. Reúne las tareas QA donde la IA se usa hoy, con qué herramienta encaja mejor, cuánto tiempo ahorra de verdad y cómo se comporta el consumo de tokens.

La regla práctica que sale de esta tabla: la IA aporta más cuanto más mecánica y mejor definida es la tarea. Para todo lo que toca diseño de estrategia, criterio de qué probar o decisiones sobre qué automatizar, el peso sigue estando en el QA.

Qué tareas QA conviene no delegar todavía a la IA

Tan importante como saber dónde usar IA es saber dónde no. Estas son las áreas en las que, en 2026, la IA o no aporta o introduce riesgos que no compensan:

• Decidir la estrategia de testing de un producto nuevo. Un LLM no conoce el contexto de negocio, ni los riesgos reales, ni las prioridades del equipo. Puede ayudarte a estructurar la conversación, no a tomar la decisión.
• Priorizar bugs en producción. El criterio de severidad pasa por el impacto en usuarios reales, en métricas de negocio y en compromisos con clientes. Eso lo tiene el QA, no el modelo.
• Pruebas de accesibilidad reales. Hay herramientas IA que detectan problemas visuales, pero la accesibilidad de verdad implica probar con lectores de pantalla, teclado y casos reales. La IA es un apoyo, no un sustituto.
• Pruebas de seguridad sensibles. Nunca pegar datos reales, credenciales o información personal en un chat público. Con MCP en local el riesgo se reduce, pero sigue requiriendo criterio.
• Validación final antes de release. El responsable de dar el OK sigue siendo el QA. Si la IA escribió los tests, los revisas tú; no al revés.

Cómo empezar si todavía no lo haces

Si estás entrando al sector o llevas poco tiempo, el orden recomendado es claro:

1. Domina un chat LLM (Claude.ai o ChatGPT) para casos de prueba, bug reports y datos de prueba. Es gratis o casi, y cubre el 70% del valor.
2. Aprende a pedir tests automatizados a un chat y a llevarlos al repo a mano. Aún sin Claude Code, mejoras mucho la velocidad.
3. Da el salto a Claude Code o Codex cuando ya tengas un proyecto de automation en marcha. Sin proyecto de tests propio, la herramienta no se aprovecha.
4. Configura un MCP útil (Jira o GitHub) en cuanto tengas un caso de uso claro y recurrente.
5. Mantén los agentes de UI en el radar, pero no construyas tu suite de regresión sobre ellos todavía.

La curva de aprendizaje es corta para lo primero y se va abriendo para lo último. Y, sobre todo, lo que más diferencia hace no es la herramienta, sino tu criterio para decidir qué pedirle y qué hacer con la respuesta.

Si quieres ver cómo encaja esto en un puesto QA real, te interesa también el artículo sobre cómo probar productos construidos con IA y el que analiza si la IA reemplazará a los QA Testers.