QA Engineer vs SDET vs QA Automation Engineer: Cual es la Diferencia Real?

El mismo título "SDET" puede describir a alguien que hace clic manualmente en una app web y a alguien que diseña infraestructura para una plataforma de tests usada por 200 ingenieros, porque la industria nunca estandarizó qué trabajo corresponde a cada título. Filtrar tu búsqueda de empleo por título desperdicia meses en los roles equivocados. Este artículo cubre lo que cada uno de los tres títulos realmente indica en las ofertas de trabajo de 2026, las diferencias reales de habilidades entre ellos, y cómo leer los requisitos en lugar de los títulos al evaluar si una posición coincide con tu perfil.

Por qué los títulos de trabajo en QA están completamente rotos

La mayoría de las industrias tiene títulos que significan más o menos lo mismo en distintas empresas. Un contador de plantilla hace trabajo contable. Un ingeniero civil diseña cosas de ingeniería civil. En QA, el mismo título puede describir dos trabajos que casi no comparten nada en el día a día.

El caos viene de varias fuentes. El testing como disciplina evolucionó rápido: desde testers manuales dedicados en los 90, hasta roles enfocados en automatización en los 2000, hasta puestos con fuerte componente de ingeniería hoy. Los títulos nunca se estandarizaron en la industria. Las empresas también copian y pegan títulos de bolsas de trabajo sin pensar qué significan. Alguien en RRHH ve "QA Automation Engineer" en una oferta de la competencia y republica el mismo título aunque el trabajo real sea 90% manual. Los requisitos de automatización también cambiaron drásticamente en poco tiempo, y el mercado no se puso al día con el vocabulario.

El resultado: "QA Engineer", "Software QA Engineer", "QA Automation Engineer", "SDET" y "Software Development Engineer in Test" pueden describir desde hacer clic en una app web manualmente hasta diseñar infraestructura para una plataforma de tests usada por 200 ingenieros.

Eso significa que no puedes usar el título para entender el trabajo. Tienes que leer los requisitos reales.

Qué significa "QA Engineer" hoy

Históricamente, QA Engineer significaba testing manual. Testing exploratorio, escribir casos de prueba en hojas de cálculo o Jira, rastrear bugs, quizás coordinar la aprobación de releases. Sin código requerido.

Esa definición está casi obsoleta, pero el título persiste y hoy puede significar una amplia gama de cosas. En la práctica, cuando una empresa publica un rol de "QA Engineer" en 2026, generalmente quiere a alguien que hace testing manual como trabajo principal con algo de automatización al costado. "Algo de automatización" puede significar ejecutar los tests de Playwright de otra persona, escribir algunos scripts en un framework existente, o mantener colecciones de Postman para smoke tests de API.

Un escenario ilustrativo: una startup de 40 personas tiene un equipo de producto que lanza funcionalidades cada dos semanas. Publican una oferta de "QA Engineer". Lo que realmente necesitan es a alguien que trabaje estrechamente con desarrolladores y product managers, detecte problemas antes de que las funcionalidades salgan, escriba casos de prueba que documenten el comportamiento esperado, y sea responsable de la conversación de calidad durante la planificación del sprint. Si esa persona también puede escribir algunos smoke tests automatizados, bien. Pero el rol es fundamentalmente sobre el juicio de calidad del producto, no sobre el output de ingeniería.

Ese es el punto óptimo del QA Engineer en la mayoría de las contrataciones en empresas no tech: alguien que entiende el producto en profundidad, comunica los defectos claramente, y tiene suficiente exposición a la automatización para no ser frenado por ella.

El rango salarial para QA Engineers en este sentido tradicional es el más bajo de los tres títulos aquí tratados. La brecha refleja la diferencia en la demanda técnica, no un juicio de valor sobre el trabajo.

Qué significa SDET y de dónde viene

SDET significa Software Development Engineer in Test. Microsoft creó este título a principios de los 2000 y la definición era precisa: un SDET escribe código de calidad de producción que prueba software, evaluado con los mismos estándares de ingeniería que los desarrolladores de software.

En Microsoft, los SDETs eran ingenieros completos que se enfocaban en testeabilidad e infraestructura de calidad en lugar de funcionalidades del producto. Diseñaban frameworks de tests, escribían herramientas que usaba el resto de la organización de QA, revisaban el código de producción por testeabilidad, y se esperaba que fueran responsables de subsistemas completos de la plataforma de tests. Un SDET senior podía pasar seis meses construyendo un sistema de ejecución de tests distribuido que reducía el tiempo de CI de dos horas a quince minutos, sin escribir ningún test de producto por su cuenta.

Esa definición con ingeniería primero se extendió, pero se diluyó. Hoy "SDET" se usa de forma inconsistente. En empresas como Amazon, Google o Meta, SDET todavía significa lo que Microsoft pretendía: ingeniería de software seria aplicada a la calidad. La barra de codificación está cerca de la barra de un ingeniero de software. En empresas más pequeñas, "SDET" a veces solo significa "queremos más rigor de ingeniería del que implica el título de QA Engineer".

Un ejemplo claro de trabajo real de SDET: una empresa con 8.000 tests end-to-end nota que su pipeline de CI tarda 90 minutos. Un SDET tiene la tarea de resolver esto. Analiza la distribución de tests, construye un sistema de sharding que paraleliza la ejecución de tests en 20 contenedores, escribe infraestructura como código para aprovisionarlos dinámicamente, y agrega herramientas de observabilidad para que los tests flaky se detecten y pongan en cuarentena automáticamente. Al final del proyecto, el tiempo total de CI es de 12 minutos. El SDET probablemente escribió 500 líneas de código de tests de producto ese trimestre y 3.000 líneas de código de framework e infraestructura.

Eso no es trabajo de QA. Es trabajo de ingeniería de software que hace posible el trabajo de QA.

Los roles de SDET en empresas que aplican el título rigurosamente pagan significativamente más que los roles de QA Engineer: típicamente un 20-35% más para niveles de seniority equivalentes, dependiendo de la empresa y la región. En las grandes empresas tech específicamente, los SDETs a menudo están en la misma banda de compensación que los ingenieros de software.

Qué significa QA Automation Engineer

Esta es la posición intermedia, y es el título más común que verás en 2026.

Un QA Automation Engineer escribe tests automatizados y mantiene el framework en el que corren esos tests. Está más enfocado en código que un QA Engineer tradicional (la automatización no es una tarea secundaria, es el trabajo principal), pero no está construyendo infraestructura de tests desde cero como hace un verdadero SDET. Trabaja dentro de un framework existente, extendiéndolo y escribiendo la cobertura real de tests.

En la práctica: un equipo usa Playwright con TypeScript, tiene una estructura de Page Object Model en lugar, y ejecuta tests en GitHub Actions. Un QA Automation Engineer se une y pasa el 70-80% de su tiempo escribiendo nuevos tests para funcionalidades a medida que se lanzan, actualizando tests existentes cuando cambia la UI, investigando tests flaky, y mejorando la confiabilidad de los tests. Puede agregar una utilidad helper al framework, mejorar el reporte de errores, o configurar una nueva suite de tests para una nueva parte del producto. Rediseñar la arquitectura del framework es territorio de SDET.

El escenario se ve así: un desarrollador lanza un nuevo flujo de checkout. El QA Automation Engineer lee los criterios de aceptación, escribe seis tests de Playwright que cubren el camino feliz y los casos extremos clave, los ejecuta localmente contra el entorno de staging, detecta dos casos extremos que no estaban manejados, reporta los bugs, y mergea los tests a main una vez que los bugs se corrigen. Un trabajo de rutina de dos días. Sin diseño de framework, sin trabajo de infraestructura. Solo cobertura sólida y bien estructurada de tests automatizados para una funcionalidad real.

Ese es el trabajo del QA Automation Engineer. Requiere capacidad real de código: escribir código de tests limpio y legible en un lenguaje real, entender patrones async, trabajar cómodamente con control de versiones, y depurar fallos sin ayuda del desarrollador. No requiere formación en ingeniería de software.

El salario está entre el QA Engineer y el SDET. Las empresas que contratan QA Automation Engineers generalmente están dispuestas a pagar notablemente más que por QA tradicional porque necesitan output de código, pero no están ejecutando un ciclo completo de entrevistas de ingeniería.

Cómo determinar qué quiere realmente una oferta

Ignora el título por completo. Ve directo a la sección de requisitos y busca tres señales.

Señal 1: ¿Qué lenguaje de codificación y framework mencionan?

Si dicen "experiencia con Playwright, Selenium o Cypress", quieren automatización de tests. Si especifican "sólidas habilidades de programación en Python o Java" y luego listan trabajo de construcción de frameworks o de "infraestructura de tests", estás mirando territorio SDET. Si los requisitos mencionan Jira, TestRail o "documentación de casos de prueba" pero el código es opcional o secundario, es un rol de QA más inclinado al manual.

Señal 2: ¿Qué implica el trabajo diario?

"Escribirás tests automatizados para nuevas funcionalidades" es trabajo de QA Automation Engineer. "Diseñarás y mantendrás nuestro framework de automatización de tests" se inclina hacia SDET. "Coordinarás el testing en los releases y gestionarás el ciclo de vida de los defectos" es QA Engineer tradicional.

Señal 3: ¿Con quién dicen que trabajarás?

Trabajar estrechamente con "product managers y desarrolladores" señala enfoque en la calidad del producto (QA Engineer). Trabajar con "el equipo de plataforma para mejorar la confiabilidad del CI" o con "ingenieros de infraestructura" señala trabajo de tipo SDET.

Un ejemplo real de contraste. La oferta A dice: "3+ años de experiencia en automatización, Playwright o Selenium requerido, sólidas habilidades en TypeScript, experiencia escribiendo suites de tests E2E". Eso es un rol de QA Automation Engineer independientemente de lo que diga el título.

La oferta B dice: "Se requieren sólidas habilidades de codificación, experiencia construyendo frameworks de tests, conocimiento de sistemas distribuidos es un plus, diseñar infraestructura de tests para soportar a cientos de ingenieros". Eso es un rol de SDET aunque el título diga "QA Engineer".

También leer la sección de "deseable". Si listan Docker, Kubernetes, administración de plataforma CI, o herramientas de observabilidad de tests como bonus, la empresa está pensando en términos de SDET aunque el título no lo diga.

Qué camino apuntar según tu perfil

Si vienes de un entorno completamente no técnico (soporte, gestión de proyectos, análisis de negocios), empieza con el camino de QA Engineer. Construye los fundamentos de testing, familiarízate con Jira y el seguimiento de defectos, y agrega habilidades básicas de automatización con el tiempo. El rol de QA Engineer es el punto de entrada más accesible porque las empresas valoran más el pensamiento de producto y la comunicación que el output de código.

Si tienes algo de experiencia en código (bootcamp de desarrollo web, experiencia en scripting, trabajo de IT), ve directo al QA Automation Engineer. Ya tienes el modelo mental para escribir código; lo que necesitas es conocimiento específico de testing encima: cómo se estructuran las suites de tests, Playwright, integración con CI. Este es el camino más rápido hacia un rol de QA bien remunerado para la mayoría de los reconvertidos de carrera.

Si tienes formación en desarrollo de software, un título en ciencias de la computación, o varios años de experiencia en desarrollo, el SDET es el objetivo correcto. La diferencia salarial es sustancial y el trabajo es genuinamente interesante a nivel técnico. El proceso de entrevistas es más difícil pero tus habilidades existentes se transfieren directamente.

Una cosa a destacar: el título de QA Automation Engineer es donde ocurre la mayor parte del crecimiento de carrera para quienes entran como QA Engineers y quieren avanzar sin pivotear al desarrollo puro. Agregar habilidades de automatización sobre una base de QA Engineer es un camino confiable hacia mayor compensación y trabajo más interesante.

Qué significa esto para tu búsqueda de empleo

Deja de filtrar por título. Filtra por requisitos. Cuando estés construyendo tu lista de aplicaciones, haz dos verificaciones rápidas en cada oferta: ¿el trabajo real descrito coincide con mi nivel de habilidad actual?, y ¿la expectativa de codificación coincide con lo que puedo demostrar en una entrevista?

Si apuntas a roles de QA Automation Engineer, tu portafolio necesita mostrar código de tests. No descripciones de trabajo de automatización. Archivos de tests reales en GitHub, organizados limpiamente, con un readme que explique qué hacen los tests y cómo ejecutarlos. Un hiring manager quiere ver código de tests que un desarrollador respetaría: legible, mantenible, bien organizado.

Si apuntas a roles de SDET, necesitas eso más evidencia de juicio de ingeniería. Decisiones de diseño de framework que tomaste y por qué. Trabajo de infraestructura. Idealmente, algo que construiste que otras personas usaron. La entrevista de SDET profundizará más allá de "¿puedes escribir un test de Playwright?", así que prepárate para discutir compensaciones de diseño.

Si apuntas a roles de QA Engineer, tu portafolio debe mostrar pensamiento de calidad: reportes de bugs bien escritos, planes de prueba para funcionalidades no triviales, ejemplos de casos extremos que detectaste que importaron. La automatización es un bonus, no el argumento central.

El mercado paga más por roles más arriba en el espectro de ingeniería. Eso no es un argumento de que el trabajo de QA tradicional es menos valioso; el buen juicio de calidad del producto es genuinamente difícil de encontrar. Es una observación factual sobre lo que el mercado actualmente valoriza. Saber en qué dirección estás construyendo te ayuda a invertir tu tiempo de aprendizaje en los lugares correctos.