Un QA Automation Engineer escribe y mantiene código que prueba software de forma automática, mientras el QA Manual explora el producto y valida comportamiento con criterio humano. La diferencia central no es la herramienta: es que el automation engineer construye software (frameworks de test, pipelines, infraestructura de pruebas) y por eso su rango salarial y su techo de carrera son más altos.

La confusión entre los dos roles es habitual y cuesta caro en entrevistas. Muchos perfiles llegan diciendo "hago testing automatizado" porque grabaron algunos scripts, y se caen ante la primera pregunta sobre estrategia de test o manejo de flakiness. Esta guía separa con precisión qué hace cada rol, qué stack se pide hoy y cómo se hace la transición.

QA Manual vs QA Automation: la diferencia real

No es que uno sea la versión avanzada del otro. Son funciones distintas que se complementan.

El error conceptual más común es pensar que la automatización reemplaza al testing manual. No lo hace: automatizás lo que ya sabés que tiene que funcionar. Descubrir qué tiene que funcionar sigue siendo trabajo humano. Los equipos maduros tienen las dos capacidades, a veces en la misma persona.

Qué hace un QA Automation Engineer en el día a día

Más allá de "escribir tests", el trabajo real se reparte así:

• Diseñar la estrategia de pruebas. Decidir qué se prueba en cada nivel: unitario, integración, end-to-end. Esta es la decisión de mayor impacto y la que más distingue a un senior.

• Construir y mantener el framework. Estructura del proyecto de tests, manejo de datos de prueba, page objects, fixtures, reportería. Es desarrollo de software, con las mismas exigencias de calidad.

• Integrar los tests en el pipeline. Que corran en cada pull request, en paralelo, con resultados legibles. Sin esto, la suite se vuelve decorativa.

• Combatir el flakiness. Tests que fallan sin motivo aparente son el problema número uno del área. Diagnosticarlos y estabilizarlos consume una porción real del tiempo.

• Probar APIs y capas no visuales. Buena parte del valor está bajo la interfaz: contratos de API, integraciones, performance.

• Hacer que los resultados sirvan. Un reporte que nadie mira no evita ningún bug. Comunicar hallazgos al equipo es parte del rol.

El stack técnico que se pide hoy

El panorama de herramientas se movió fuerte en los últimos años, y conviene saber hacia dónde.

Automatización de interfaz

• Playwright: se convirtió en el estándar de facto. Según los relevamientos del sector, ronda el 45% de adopción entre profesionales de QA frente al 22% de Selenium, y cruzó los 33 millones de descargas semanales en npm. Sus ventajas: espera automática, una sola API para Chromium, Firefox y WebKit, mocking de red nativo y ejecución en paralelo por defecto. Si empezás hoy, empezá acá.

• Cypress: se mantiene estable en torno al 14% de adopción. Excelente experiencia de desarrollo para aplicaciones web modernas, con limitaciones en escenarios multi-pestaña y multi-dominio.

• Selenium: perdió terreno, pero sigue muy presente en sistemas legados y entornos corporativos grandes. Vale conocerlo, no necesariamente empezar por él. El equipo de Stack Overflow publicó una comparativa detallada de los tres frameworks que ayuda a decidir según contexto.

Si vas a arrancar con Playwright, conviene leer directamente las buenas prácticas de la documentación oficial: la mayoría de los problemas de flakiness que se ven en equipos reales vienen de ignorar esas recomendaciones básicas sobre selectores y aislamiento de tests.

APIs, carga y soporte

• Postman y REST-assured: pruebas de API, que suelen dar más retorno por hora invertida que las de interfaz.

• k6 o JMeter: pruebas de carga y performance.

• Docker: entornos de prueba reproducibles. Cada vez más pedido.

• Git y CI/CD: no negociable. Si tus tests no corren en el pipeline, no existen.

Lenguajes

JavaScript/TypeScript domina el ecosistema de Playwright y Cypress. Python es fuerte en pruebas de API y de datos. Java sigue vigente en entornos corporativos con Selenium. Elegí uno y profundizá: saber tres lenguajes superficialmente es peor que uno bien.

Cómo hacer la transición de QA Manual a QA Automation

Si ya trabajás en testing manual, tenés la parte difícil resuelta: entendés el producto y sabés qué vale la pena probar. Falta la parte de programación.

1. Aprendé un lenguaje de verdad, no solo la sintaxis de tests. Estructuras de datos, funciones, manejo de errores, asincronía. Tres meses de fundamentos rinden más que seis de copiar scripts.

2. Automatizá un flujo real de tu trabajo actual. Elegí el caso de regresión más aburrido que ejecutás a mano y automatizalo. Tiene doble beneficio: aprendés y demostrás iniciativa donde ya trabajás.

3. Aprendé Git y CI antes de sumar más herramientas. Es lo que convierte un script en parte del proceso de desarrollo.

4. Construí un proyecto público. Una suite de tests sobre una app demo, con framework propio, corriendo en CI, con README que explique tus decisiones de diseño. Esto es tu portfolio.

5. Aprendé a hablar de estrategia. En la entrevista te van a preguntar qué automatizarías y qué no. Tener una respuesta fundada te separa del resto.

La ventaja de venir del manual es enorme y muchos la subestiman: un developer que aprende testing suele automatizar cosas que no importan. Vos ya sabés qué importa. Si querés dimensionar los rangos salariales de perfiles técnicos comparables, esta nota sobre el sueldo y el stack de un full stack developer te sirve de referencia, porque el automation engineer se ubica en un rango similar.

Qué buscan los hiring managers en una entrevista de QA Automation

Las preguntas que más se repiten y lo que están evaluando:

• "¿Qué no automatizarías?" Buscan criterio. La respuesta esperada incluye casos de usabilidad, exploratorios, features muy inestables y todo lo que cambie más rápido de lo que se puede mantener.

• "¿Cómo manejás un test flaky?" Buscan método. Reproducir, aislar la causa (timing, dependencia de datos, orden de ejecución), corregir la raíz. La respuesta incorrecta es "le pongo un retry".

• "¿Cómo estructurás una suite que crece?" Buscan pensamiento de arquitectura: separación de responsabilidades, datos de prueba independientes, ejecución paralela.

• "Mostrame código tuyo." Buscan que exista. Este es el filtro más simple y el que más gente deja afuera.

Sobre este último punto, tener el trabajo publicado y documentado cambia el resultado del proceso. Lo desarrollamos en esta guía sobre cómo armar un portfolio técnico siendo junior.

Formación recomendada de Coderhouse

No hay atajo: para automatizar hay que saber programar. Estas tres rutas cubren distintos puntos de partida:

• Si necesitás la base de programación: la Carrera de Desarrollo Full Stack te da JavaScript, lógica, APIs y despliegue, que es exactamente el terreno donde se apoya Playwright. Es la ruta más directa desde testing manual.

• Si querés sumar automatización de procesos al perfil: el Curso de AI Automation aporta la lógica de flujos, integraciones y disparadores, que se traslada bien al diseño de pipelines de prueba.

• Si te interesa el testing de aplicaciones: la carrera de Desarrollo de Aplicaciones te acerca al ciclo completo de construcción, que es el contexto donde el QA automation aporta más valor.

Empezá por el lenguaje, automatizá un caso real de tu trabajo actual y publicalo. Con eso ya tenés material para una entrevista seria.

Preguntas frecuentes

¿Un QA Automation Engineer gana más que un QA Manual?

Sí, de forma consistente. La diferencia suele ubicarse entre el 30% y el 60% para el mismo nivel de seniority, porque el rol requiere programación y su techo de carrera se conecta con perfiles de desarrollo e infraestructura. Es una de las transiciones con mejor retorno dentro de tech.

¿Necesito saber programar para hacer QA Automation?

Sí. Existen herramientas low-code, pero los puestos que pagan bien y son estables piden escribir y mantener código. El nivel necesario no es el de un desarrollador full stack, pero sí incluye estructuras de datos, asincronía, manejo de errores y capacidad de leer el código de la aplicación que estás probando.

¿Playwright, Cypress o Selenium: cuál conviene aprender?

Playwright, si estás empezando hoy. Tiene la mayor adopción actual, la mejor experiencia de desarrollo y cubre los tres motores de navegador con una sola API. Selenium sigue siendo útil conocerlo por la cantidad de sistemas legados que lo usan, pero no conviene que sea tu primera herramienta.

¿La inteligencia artificial va a reemplazar al QA Automation Engineer?

Está cambiando la tarea, no eliminando el rol. La IA genera casos de prueba, sugiere selectores y ayuda a diagnosticar fallas, lo que reduce el tiempo de escritura de tests. Lo que no resuelve es decidir qué probar, diseñar la arquitectura de la suite ni interpretar por qué algo falla en un contexto de negocio específico. Esas son las partes donde se concentra el valor del rol.

¿Cuánto tarda pasar de QA Manual a QA Automation?

Entre 6 y 12 meses con dedicación consistente, si ya trabajás en testing. La mayor parte del tiempo se va en aprender a programar bien, no en aprender la herramienta de automatización. Automatizar casos reales de tu trabajo actual acelera mucho el proceso porque combina práctica con visibilidad interna.