Durante años, la industria del software cometió un error silencioso: confundió automatización de pruebas con ingeniería de calidad, y puso ambas responsabilidades en el mismo rol.
El resultado fue predecible: QAs funcionales aprendiendo Selenium, Cypress o Playwright a medias, suites de regresión frágiles que nadie mantiene, y pipelines de CI que fallan por razones que nadie entiende. Todo esto mientras los desarrolladores seguían sin sentir ninguna responsabilidad real por la calidad del código que escribían.
La llegada de la IA generativa no vino a empeorar este escenario. Vino a exponerlo.
El error de origen: automatizar es programar
Escribir pruebas automatizadas con Playwright, Gherkin o cualquier herramienta moderna es programar. Requiere entender el DOM, gestionar dependencias, manejar asincronía, diseñar abstracciones reutilizables y depurar errores de integración. No es una habilidad adyacente al testing funcional — es una disciplina de ingeniería de software.
Pedirle a un QA funcional que automatice sin una formación técnica sólida equivale a pedirle a un médico que diseñe el quirófano. Puede tener criterio clínico excelente, pero no es su oficio construir la infraestructura.
Y sin embargo, el mercado lleva una década publicando ofertas de "QA Automation Engineer" esperando ambas cosas en un mismo perfil: alguien que conozca el dominio del negocio, defina escenarios de prueba, automatice con frameworks modernos y los integre al pipeline de CI/CD. Es un unicornio. Y los unicornios son caros, escasos y frecuentemente mal aprovechados.
Lo que la IA cambia, y lo que no
Hoy, un desarrollador puede abrir Copilot, Cursor o Claude y decirle: "Genera los casos de prueba end-to-end para este flujo de checkout usando Playwright." La IA analizará el código, inferirá los caminos críticos, sugerirá casos borde y producirá pruebas ejecutables en minutos.
Esto no elimina el juicio técnico — todavía hace falta un desarrollador que evalúe qué generar, revise lo generado y lo integre correctamente. Pero sí elimina la barrera de entrada que antes justificaba tener un especialista separado para la tarea.
Lo que la IA no puede hacer es lo que siempre debió hacer el QA:
- Entender el negocio con profundidad suficiente para detectar que un escenario técnicamente correcto es funcionalmente absurdo.
- Validar que la experiencia de usuario es coherente, no solo que los assertions pasan.
- Cuestionar si se está construyendo lo correcto, no solo si se está construyendo correctamente.
- Pensar en calidad de punta a punta: desde los requisitos hasta producción.
El modelo que propongo: desarrolladores automatizan, QA garantiza
La propuesta no es eliminar el rol de QA. Es devolverle su propósito original.
En el marco del Testing Ágil de Lisa Crispin y Janet Gregory, el QA no es un verificador de última milla. Es un agente de calidad que opera en todos los cuadrantes: desde las pruebas que guían el desarrollo (criterios de aceptación, pruebas de negocio) hasta las que evalúan el producto desde afuera (pruebas exploratorias, usabilidad, atributos de calidad).
El modelo que tiene sentido hoy es este:
Los desarrolladores, apoyados por IA, son responsables de:
- Evaluar la criticidad de cada funcionalidad.
- Crear y mantener los casos de prueba automatizados (unitarios, integración, e2e).
- Integrarlos en el pipeline de CI/CD.
- Asegurar la cobertura técnica del código que escriben.
El QA, liberado de escribir scripts, es responsable de:
- Definir la estrategia de calidad del proyecto.
- Validar los escenarios de prueba generados por los developers.
- Definir, monitorear e interpretar las métricas de calidad — defect density, escape rate, flakiness rate, cobertura de riesgo, tiempo medio de detección — como base para la toma de decisiones y para identificar causas raíces antes de que se conviertan en problemas sistémicos.
- Ejecutar testing exploratorio donde la IA y la automatización tienen puntos ciegos.
- Ser la voz del usuario y del negocio dentro del equipo técnico.
- Monitorear la calidad de principio a fin, no solo al final del sprint.
Los argumentos en contra que ya escucho
"Los desarrolladores no tienen incentivo para escribir buenas pruebas de su propio código."
Es una crítica válida, pero apunta a un problema de cultura y ownership, no a una razón para mantener el status quo. La solución no es tercerizar la responsabilidad — es construir equipos donde la calidad sea compartida. Y la IA, al reducir el costo de escribir pruebas, elimina la excusa más común: "no tenemos tiempo."
"El QA funcional sí puede aprender a automatizar."
Puede. Algunos lo hacen excelente. Pero el punto no es si es posible — es si es lo más valioso que esa persona puede aportar. Un QA con visión de negocio, criterio exploratorio y capacidad de cuestionar requisitos desde la raíz genera más valor que uno que pasa el 60% de su tiempo debugueando selectores CSS rotos.
"Pero si los developers automatizan, ¿quién controla que la calidad realmente mejora?"
Precisamente el QA — y con más rigor del que permite estar ocupado manteniendo scripts. Un QA con foco estratégico puede establecer el sistema de métricas que le diga al equipo, con datos, si la calidad avanza o retrocede: cuántos defectos escapan a producción, en qué componentes se concentran las fallas, cuánto tarda el equipo en detectar un bug introducido, qué tan confiable es la suite automatizada que escribieron los developers. Esas métricas no son reportes para la gerencia — son el radar de causas raíces. Son lo que permite distinguir si un problema es de código, de requisitos, de proceso o de diseño, antes de que se vuelva una crisis. Ninguna herramienta de IA genera ese criterio sola. Lo genera un QA que entiende el negocio, conoce el historial del producto y sabe qué preguntas hacerle a los números.
Una redefinición que ya está ocurriendo
Los equipos de ingeniería más maduros ya están ahí. En organizaciones con cultura DevOps consolidada, el testing automatizado es responsabilidad del developer — no como carga extra, sino como parte natural del ciclo de escritura de código. El QA en esos equipos trabaja en estrategia, en riesgo, en exploración y en la voz del usuario.
La IA no inventó este modelo. Solo lo vuelve ineludible para el resto.
La pregunta no es si los QAs deben seguir automatizando. La pregunta es cuánto tiempo más vamos a seguir confundiendo escribir scripts con garantizar calidad.
Son cosas distintas. Siempre lo fueron.
¿Tu equipo ya separó estos roles, o todavía el QA carga con ambos mundos? Me interesa leer experiencias en los comentarios.
#QualityAssurance #TestAutomation #AgileTesting #DevOps #SoftwareQuality #IA #ShiftLeft #TestingÁgil