← Blog

Web4 ya está en producción. ¿Tu equipo ya sabe trabajar con MCPs?

  • #web4
  • #mcp
  • #qa
  • #testing
  • #agentesia
  • #testingai
  • #qastepbystep
  • #automatizacion

This article is in Spanish, its original language. No translation is available yet.

¿Qué es Web4?

Web4 es la siguiente etapa de internet. También la llaman la "Web Simbiótica": el momento en que humanos y máquinas dejan de trabajar en turnos y empiezan a trabajar juntos, en tiempo real, de forma autónoma.

La Unión Europea ya tiene una estrategia oficial desde 2023 para prepararse para este paradigma.

Para entender dónde estamos parados, el repaso rápido:

Evolución de la WEB1, WEB2, WEB3 y WEB4.

En Web4, las apps no esperan que les pidas algo. Actúan. Deciden. Reportan según lo programado.

¿Y los MCPs? ¿Qué son?

MCP = Model Context Protocol.

Es el conector entre el agente de IA y las aplicaciones externas: Notion, GitHub, Jira, Qase, Slack, bases de datos, lo que sea.

Sin MCP, el agente vive aislado. Con MCP, el agente puede entrar a tus herramientas, leer información, ejecutar acciones y devolver resultados. Es el puente.

Con eso, un agente puede leer un requisito en Notion → generar casos de prueba → ejecutarlos → abrir el ticket en Jira con el resultado. Siempre dentro de los límites para los que fue configurado. Sin intervención humana en cada paso.

Es lo que REST fue para las APIs hace 15 años: el estándar que desbloqueó un ecosistema entero.

API, SDK y MCP: ¿cuál es la diferencia?

Antes de hablar del impacto en QA, vale la pena aclarar tres términos que se confunden todo el tiempo:

API es el conjunto de reglas que permite que dos aplicaciones se comuniquen. Es la base de todo. Cuando hacés un GET /users, estás usando una API.

SDK es un paquete que facilita el uso de esa API en un lenguaje específico. Te da las bibliotecas, las herramientas y la documentación para no tener que escribir todo desde cero. El AWS SDK para JavaScript es un ejemplo clásico.

MCP es una capa por encima de todo eso. Es el protocolo estandarizado (oficializado en 2025 por la Linux Foundation) que permite que un modelo de IA descubra y llame dinámicamente a herramientas y APIs, sin que nadie le haya escrito código personalizado para cada caso.

API, SDK y MCP: ¿cuál es la diferencia?

En Web4, el QA necesita entender los tres niveles. Las APIs y SDKs siguen siendo el núcleo de los sistemas. El MCP es la capa nueva que conecta esos sistemas con los agentes.

¿Qué cambia para el QA?

Según las buenas prácticas de ISO y ISTQB, el proceso de testing cubre planificación, análisis, diseño, implementación, ejecución y cierre. En Web4, varias de esas fases las empieza a ejecutar la IA.

Esto ya se está comenzando a medir:

60–85% de reducción en esfuerzo de testing en tareas repetitivas

+85% de cobertura en equipos que adoptaron herramientas agentic

58% de las empresas ya están capacitando a sus equipos en IA (tendencias 2026)

¿Qué tipos de prueba requiere Web4?

  • Pruebas agentic: validar que el agente se comporta bien ante contextos ambiguos o fallas encadenadas, siempre dentro de los límites para los que fue entrenado y configurado.

  • Testing multimodal: visual + API + accesibilidad + UX en un solo flujo E2E.

  • Chaos engineering continuo: resiliencia en sistemas donde los agentes actúan en tiempo real, según sus parámetros definidos.

  • Testing no determinístico: cuando el mismo input puede dar respuestas distintas. Los casos de prueba estáticos no alcanzan.

¿Qué pasa con la trazabilidad según el compliance local?

En fintech, salud y banca, auditar las decisiones del sistema no es una buena práctica: es una obligación legal. ISO 25010, GDPR, normativas del BCRA, regulaciones de la CMF, leyes de protección de datos en LATAM: todas exigen saber qué hizo el sistema, cuándo y por qué.

Cuando un agente ejecuta acciones encadenadas vía MCP, ¿quién documenta ese flujo? ¿Queda guardado en los logs? ¿Cómo se audita ante un ente regulador? ¿Cómo se demuestra que el agente actuó dentro de los parámetros permitidos?

El QA que sabe responder eso tiene un valor diferencial que hoy muy pocos perfiles tienen, especialmente en mercados regulados de LATAM.

Lo que Web4 NO reemplaza

Los agentes de IA pueden ejecutar, generar y detectar dentro de lo que fueron entrenados para hacer.

Lo que no pueden hacer es leer entre líneas de un negocio. No entienden por qué ese flujo existe, qué regulación lo condiciona, o qué impacto real tiene un bug para el usuario final.

No detectan que algo "no se siente bien" aunque pase todas las validaciones. No anticipan riesgos que todavía no están escritos en ningún backlog. No negocian con stakeholders ni traducen criterios de aceptación ambiguos en casos de prueba concretos.

El rol en riesgo no es el del QA. Es el del QA que nunca evolucionó más allá de ejecutar casos manuales y scripts automatizados estáticos.

Los roles que están creciendo tienen nombre:

  • 🧠 AI QA Engineer → testea sistemas IA y valida outputs de modelos

  • 📊 Test Strategist → define estrategias híbridas manual/IA

  • 🎛 QA Orchestrator → supervisa agentes autónomos en pipelines CI/CD

¿Por dónde empezar para estar al día con los agentes de IA?

1. Consolidá las bases del testing manual. Si no sabés qué necesitás probar, no vas a obtener buenos resultados de los agentes. Sin dominar análisis de riesgos y diseño de casos de prueba, es muy difícil supervisar a agentes que hacen eso de forma autónoma. Los fundamentos no se saltan, se profundizan. 👉 Carrera QA Manual en Academia QA

2. Incorporá la IA como habilidad técnica real. Prompting avanzado para generación de casos, configuración de agentes, validación crítica de lo que la IA produce. No como un truco. Como una competencia que ya te diferencia en el mercado. 👉 Practicá con el programa TestingAI

3. Desarrollá pensamiento de datos. SQL para ir directo a la base de datos, lectura de logs, interpretación de métricas de calidad. En Web4, la raíz de los problemas vive en los datos más que en la interfaz.

El momento es ahora

La dinámica de la industria es siempre la misma: primero aparece la tecnología, después llegan los proyectos que la usan, y para ese momento ya es tarde para aprender desde cero.

Web4 y los MCPs no son una promesa. Ya están en producción.

Un caso concreto: los agentes de Base (la red L2 de Coinbase) ya permiten crear bots que ejecutan swaps, staking y bridges de forma autónoma onchain de criptomonedas y stablecoins, configurables en menos de 5 minutos, dentro de los límites de seguridad definidos por el usuario. Eso es Web4 funcionando hoy.

En el mundo del desarrollo, herramientas como Claude Code de Anthropic ya operan con MCPs de forma nativa: el agente se conecta a GitHub, lee el repositorio, escribe código, abre PRs, escribe casos de prueba, ejecuta pruebas funcionales y de backend y escribe reportes de error directamente en Jira, todo desde una instrucción en lenguaje natural. Los equipos de dev ya lo están usando. ¿Vos ya los sabés usar? ¿Te están ahorrando tiempo? ¿Quién está validando que esos agentes hagan lo correcto?

La brecha entre los equipos de dev y los equipos de QA en este tema es real. Y esa brecha es, al mismo tiempo, un riesgo y una oportunidad.

En Academia QA estamos formando a los profesionales que el mercado necesita para esta etapa.

El software está cambiando. Los equipos que lo prueban también tienen que cambiar.

¿Te sumás a la conversación? Compártilo con alguien de tu equipo que todavía no esté usando MCPs.

Got a problem where many pieces must fit together?

Tell me about your product, your data or your payment flow, and let's book a call.