Cómo Convertirse en QA Engineer en 2026: El Roadmap Completo (Sin Título)

La mayoría de los principiantes pierde meses en ejercicios de programación abstractos antes de escribir un solo test. El camino mejor es Playwright primero: escribe un test real contra un sitio web real desde el primer día, y usa la confusión con el lenguaje que te vayas encontrando como señal de qué estudiar después. Esta guía cubre exactamente las habilidades que requieren las ofertas laborales junior en 2026, el orden correcto para aprenderlas, y qué debe tener un portfolio para pasar una evaluación técnica.

El rol tiene dos variantes y conviene elegir una pronto

Cuando la mayoría de la gente dice "ingeniero QA" se refiere a dos trabajos distintos. Los QA manuales exploran el software a mano, escriben casos de prueba, reportan bugs y comunican los hallazgos a desarrolladores y product managers. Los QA de automatización escriben código que testea el software automáticamente, ejecutando checks en cada despliegue sin que ningún humano haga clic en nada.

El manual es más fácil de entrar. La automatización paga significativamente más y tiene mejor trayectoria de carrera a largo plazo. El salario promedio para un ingeniero QA de automatización en EE.UU. es $95.000–$115.000 dependiendo de la ubicación y el tamaño de la empresa. Los roles de QA manual suelen estar $20.000–$30.000 por debajo.

Esta guía cubre el camino de automatización, porque es hacia donde se mueve el mercado y donde está el crecimiento profesional compuesto. Si estás empezando desde cero, ese es el camino que vale la pena tomar.

La buena noticia: no necesitas un título universitario en informática para ninguno de los dos roles. Decenas de ingenieros QA de automatización en actividad empezaron como docentes, representantes de atención al cliente, project managers y contadores. Las habilidades técnicas son aprendibles. Lo que realmente vendes en una entrevista laboral es prueba de que las aprendiste.

Las únicas habilidades técnicas que importan para el primer trabajo

Las ofertas para roles junior de QA de automatización en 2026 se concentran en la misma lista corta. Si ves una oferta pidiendo 15 habilidades específicas, la mayoría son aspiracionales. Lo que realmente te hace pasar el filtro técnico es esto:

Playwright o Selenium (Playwright es muy preferido para quien empieza ahora), JavaScript o TypeScript (TypeScript es lo que usan la mayoría de los proyectos modernos), testing básico de API, Git, y algún entendimiento de cómo funciona CI. Eso es todo. El resto es nice-to-have que se aprende en el trabajo.

Un ejemplo de qué hace un ingeniero QA de automatización junior el primer día: clonar un repositorio de tests, ejecutar el suite existente, ver que algunos tests pasan y otros fallan, y la primera tarea es entender por qué fallan los que fallan. Para eso se necesita Git para bajar el código, Node.js para ejecutarlo, TypeScript para leerlo, y Playwright para entender los errores. Nada más. Sin certificación, sin checklist de 30 habilidades.

Empieza con Playwright antes que cualquier otra cosa

Esta es la parte contraintuitiva del roadmap. La mayoría empieza "aprendiendo programación" porque eso es lo que dicen las guías de carrera. El problema con ese enfoque es que los ejercicios de programación pura son abstractos y se vuelven aburridos rápido. Vas a pasar semanas en problemas de fizzbuzz y manipulación de arrays mientras que el motivo real por el que querías aprender (romper y testear software) sigue permanentemente en el futuro.

Empieza con Playwright primero. Acepta que vas a copiar y pegar código que no entiendes del todo. Ejecutalo. Velo funcionar. Rompelo deliberadamente. Mirá qué error devuelve.

Acá está el primer test real que vale la pena escribir, usando lab.becomeqa.com:

import { test, expect } from '@playwright/test';

test('login con credenciales válidas', async ({ page }) => {
  await page.goto('https://lab.becomeqa.com');
  await page.getByRole('button', { name: 'Login' }).click();
  await page.getByLabel('Username').fill('admin@becomeqa.com');
  await page.getByLabel('Password').fill('testpass123');
  await page.getByRole('button', { name: 'Submit' }).click();

  await expect(page.getByText('My Travel Items')).toBeVisible();
});

Ejecutalo. Mira cómo abre un navegador, completa campos y hace clic sin que tú toques nada. Esa sensación de ver la automatización funcionar por primera vez es lo que mantiene a la gente avanzando a través de las partes más difíciles.

Después escribe un segundo test que use credenciales incorrectas y verifique que aparece el mensaje de error. Luego un tercero que cierre la sesión y verifique que la página vuelve al estado de login. Tres tests, todos en UI real, y ya practicaste locators, aserciones y estructura de tests.

JavaScript y TypeScript: aprende lo justo y sigue avanzando

Una vez que estés escribiendo tests, vas a chocar con paredes del lenguaje. Vas a ver async y await y no saber qué significan. Vas a querer guardar un valor de un paso del test y usarlo en otro, y no saber cómo funcionan las variables en llamadas await. Esos son los momentos para detenerse y aprender el concepto del lenguaje que te está bloqueando.

El JavaScript/TypeScript mínimo que necesitas antes de poder escribir tests reales: variables y const/let, funciones, arrays y objetos, async/await y por qué existe, y operaciones básicas con strings. Son aproximadamente dos o tres semanas de práctica diaria si nunca escribiste código antes.

Los conceptos que irás incorporando mientras escribís más tests: tipos e interfaces de TypeScript, destructuring, módulos e imports, y clases cuando llegues al Page Object Model.

Un ejemplo concreto de cómo async/await confunde al principio. Si escribís esto:

const text = page.getByText('Bienvenido').textContent();
console.log(text); // imprime una Promise, no el texto

Obtenés un objeto Promise en la consola, no el texto real. La versión correcta es:

const text = await page.getByText('Bienvenido').textContent();
console.log(text); // imprime 'Bienvenido'

El await le dice a JavaScript: detenete acá, esperá a que esta operación asíncrona termine, luego dame el resultado. Cada acción de Playwright usa await. Entender por qué hace que depurar sea diez veces más rápido.

El testing de API no es opcional

La mayoría de los principiantes saltea el testing de API porque parece una habilidad separada y más difícil. No es ninguna de las dos cosas. Un test de API es simplemente un request HTTP con aserciones sobre la respuesta. Sin navegador, sin clics, sin locators.

Por qué pertenece a tu lista de aprendizaje temprano: los tests de API son cinco a diez veces más rápidos que los tests de UI y fallan por menos razones no relacionadas. Un test de UI puede fallar porque un botón se movió, un spinner de carga tardó un segundo extra, o un tooltip cubrió el elemento. Un test de API falla porque los datos son incorrectos, que es lo que realmente te importa.

Playwright tiene testing de API integrado en el mismo framework que ya estás usando:

test('GET /api/items devuelve ítems de viaje', async ({ request }) => {
  const response = await request.get('https://lab.becomeqa.com/api/items');

  expect(response.status()).toBe(200);

  const body = await response.json();
  expect(body.length).toBeGreaterThan(0);
  expect(body[0]).toHaveProperty('destination');
  expect(body[0]).toHaveProperty('id');
});

Sin herramientas nuevas. Sin framework separado. Las mismas funciones test y expect que ya conocés, con request en lugar de page.

Dedícate también unas horas a Postman. No porque lo vayas a usar para automatización, sino porque explorar una API manualmente antes de escribir tests para ella ahorra tiempo. Envías requests, ves la forma de las respuestas, entiendes los headers de autenticación, y entonces el código del test tiene sentido en lugar de ser copiado ciegamente de la documentación.

Construí algo que puedas mostrar, no solo algo que entiendas

Acá es donde la mayoría de quienes aprenden solos se estanca. Hacen tutoriales, escriben ejercicios y sienten que están progresando. Después alguien pregunta "¿puedo ver tu trabajo?" y no hay nada que mostrar.

Los hiring managers miran perfiles de GitHub para candidatos QA junior. No porque esperen suites de tests pulidas y de nivel senior. Porque un repositorio en GitHub prueba que realmente escribiste el código y no solo viste videos al respecto.

Un portfolio que te consiga entrevistas es directo: un repositorio en GitHub con un suite de tests de Playwright que cubra un sitio web real, configuración con TypeScript, un Page Object Model para al menos dos páginas, tests tanto de UI como de API, y un workflow de GitHub Actions que ejecute los tests en cada push. Eso es todo. Ese es el estándar.

La parte del Page Object Model suena intimidante antes de hacerla. El concepto: en lugar de escribir page.getByLabel('Username').fill(username) en cada test que necesita hacer login, creás una clase LoginPage con un método login(username, password). Los tests llaman loginPage.login('admin@becomeqa.com', 'testpass123'). Si el formulario de login cambia alguna vez, lo corregís en un solo lugar.

// pages/LoginPage.ts
export class LoginPage {
  constructor(private page: Page) {}

  async login(username: string, password: string) {
    await this.page.getByRole('button', { name: 'Login' }).click();
    await this.page.getByLabel('Username').fill(username);
    await this.page.getByLabel('Password').fill(password);
    await this.page.getByRole('button', { name: 'Submit' }).click();
  }
}

Usa lab.becomeqa.com como el sitio que automatizás para tu portfolio. Tiene suficiente complejidad (login, tablas de datos, modales, carga de archivos, endpoints de API) para demostrar habilidades reales sin que el sitio se caiga ni bloquee el tráfico automatizado.

Cómo aplicar esto el lunes a la mañana

Si estás leyendo esto un domingo a la noche y quieres un plan concreto para la semana que viene, acá está.

Las personas que consiguen trabajo no esperan a sentirse listas. Construyen evidencia de que pueden hacer el trabajo, la ponen en un lugar visible, y empiezan a hablar con empresas mientras siguen aprendiendo.

FAQ

Cuatro a seis meses de práctica diaria para la mayoría de las personas sin experiencia previa en programación. Menos si vienes de un background de desarrollo. Más si solo practicás los fines de semana. La variable no es el talento. Es la consistencia y la calidad de lo que construís para mostrar.

No para conseguir trabajo en la mayoría de las empresas hoy. Playwright desplazó a Selenium en la mayoría de los proyectos nuevos. Si una empresa específica que querés entrar usa Selenium, podés aprender las diferencias en una semana una vez que sabes Playwright. Los conceptos son casi idénticos, la sintaxis difiere.

ISTQB Foundation Level es la certificación más reconocida en QA. Demuestra familiaridad con la teoría y terminología de testing. Algunas empresas la filtran, la mayoría no la requiere. Si estás eligiendo entre certificarte con ISTQB y construir un proyecto de portfolio, construí el proyecto. Un repositorio en GitHub con tests funcionando es evidencia más difícil que un examen de opciones múltiples.

Tu portfolio en GitHub, específicamente. Lista el proyecto con un link, describe lo que construiste ("Suite de tests con Playwright con 40+ tests cubriendo flujos de UI y endpoints de API REST, corriendo en CI via GitHub Actions"), y menciona las tecnologías. Los recruiters ven los links de GitHub y los abren. Pones el CV frente a personas que van a hacer clic en el link antes de preocuparte por cómo phrasing todo lo demás.

Automatización. Paga más, es hacia donde va la industria, y la curva de aprendizaje está concentrada al principio. Una vez que la superas, eres empleable. Empezar con QA manual y hacer la transición a automatización después significa aprender dos veces. La única excepción es si puedes conseguir un trabajo de QA manual rápidamente y usarlo para transicionar internamente en una empresa que financie tu tiempo de desarrollo.