Roadmap de Automatización QA 2026: Habilidades Esenciales para Conseguir Trabajo

Aprender Playwright antes que JavaScript significa que vas a copiar y pegar código sin entender por qué se rompe. El orden de estas nueve habilidades es deliberado: cada una habilita la siguiente, y saltarse pasos cuesta más tiempo del que ahorra. Este roadmap cubre qué aprender en qué secuencia, con estimaciones de tiempo honestas para cada etapa y orientación sobre qué postegar hasta que realmente lo necesites.

Por qué importa el orden

No puedes escribir tests reales sin JavaScript. Punto. Y no puedes automatizar una API si nadie te explicó qué es una API. Y definitivamente no puedes configurar CI/CD cuando todavía no tienes tests que valga la pena ejecutar.

Cada habilidad aquí desbloquea la siguiente. Saltarte pasos significa el doble de tiempo confundido.

1. Playwright: tu framework de automatización

Selenium era la respuesta. Ya no lo es. No para quienes empiezan a aprender en 2026.

Playwright lo reemplazó en la mayoría de los proyectos nuevos, y las razones se vuelven obvias en el momento en que usas ambos. Espera automáticamente por los elementos en vez de hacerte adivinar tiempos de espera. Viene con un test runner integrado, grabaciones de video de los fallos, interceptación de red y un generador de código que escribe los locators mientras haces clic en la página.

Así se ve un test real de Playwright:

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

test('el usuario puede iniciar sesión', 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();
});

Limpio. Sin boilerplate. Si nada de eso tiene sentido todavía, está bien: el curso de Playwright cubre exactamente esto.

2. JavaScript/TypeScript: la capa del lenguaje

Algunas personas intentan saltarse esto e ir directo a los tests. Funciona quizás dos semanas. Después algo se rompe y no tienen ni idea de por qué, porque nunca aprendieron el lenguaje, solo lo copiaron y pegaron.

Playwright es JavaScript. TypeScript es JavaScript con tipos agregados. Los tipos atrapan los errores antes de ejecutar nada. Playwright configura TypeScript por defecto y después de una semana con él no vas a querer volver al JS sin tipos.

Lo que realmente necesitas:

Empieza con variables, tipos de datos, funciones, arrays y objetos, y async/await. Este último no es opcional. Cada acción de Playwright lo usa. Sin entender async/await estás volando a ciegas.

Después, una vez que estés escribiendo tests con regularidad: destructuring, operador spread, módulos, manejo de errores con try/catch, y clases para el Page Object Model.

No esperes a haber "terminado JavaScript" antes de tocar los tests. Es una trampa. Aprende lo esencial, empieza a escribir tests, incorpora el resto a medida que lo necesites. Los tests te dan una razón concreta para usar el lenguaje.

3. Practicar en un sitio real

La teoría sin un sitio para automatizar es solo lectura. Necesitas formularios reales, tablas reales, casos extremos reales.

La mayoría de los sitios de práctica son trivialmente simples (un botón, un campo de texto) o se caen de forma aleatoria y dan errores que no tienen nada que ver con tu código de tests. Ambas son peores que inútiles para aprender.

Construimos lab.becomeqa.com para esto. Flujo completo de login, tablas de datos ordenables, modales, carga de archivos, un formulario de pago conectado al modo de prueba de Stripe, y endpoints de API expuestos para testing directo. Se mantiene estable porque los entornos de práctica inestables enseñan los hábitos de depuración equivocados.

Otras opciones si quieres alternativas: SauceDemo, The Internet de Dave Haefner, TodoMVC. Pero lab.becomeqa.com tiene la API configurada para coincidir con los ejercicios de este curso.

4. Testing de API: más rápido y más estable que los tests de UI

La mayoría de los principiantes no sabe esto: la mayoría de los bugs en las aplicaciones web no viven en la UI. Viven en la API, la lógica del backend que la UI llama.

Los tests de UI tardan segundos. Los tests de API tardan milisegundos. Y los tests de API no se rompen porque un botón se desplazó dos píxeles a la izquierda o un spinner de carga tardó un poco más de lo esperado. Son más estables, más rápidos de escribir y detectan una categoría de bugs que los tests de UI simplemente nunca alcanzan.

Playwright tiene testing de API integrado a través del fixture request:

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

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

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

Sin navegador. Sin página. Solo HTTP. Herramientas que vale conocer: el fixture request (ya integrado en Playwright), Postman para exploración manual de APIs, y métodos HTTP básicos (cubiertos en la habilidad 7).

5. CI/CD: hacer que tus tests sean realmente útiles

Los tests que solo corren en tu computadora no detectan bugs en producción. Detectan bugs después de que casualmente los ejecutás a mano. Eso no es automatización, es testing manual retrasado.

Los pipelines de CI/CD ejecutan tus tests en cada commit, cada PR, cada despliegue. Automáticamente.

GitHub Actions

Empieza aquí. Cuenta gratuita, sube tu código, agrega un archivo .github/workflows/tests.yml y tus tests se ejecutan en cada push. La comunidad es enorme y encontrar ejemplos lleva minutos, no horas.

GitLab CI

Mismo concepto que GitHub Actions. Común en empresas medianas. Si conoces uno, puedes aprender el otro en un día. La sintaxis difiere levemente, el modelo mental es idéntico.

Jenkins

Antiguo, complicado de configurar, todavía presente en muchas empresas. Lo vas a encontrar eventualmente. No empieces con él.

Lleva tus tests de Playwright a GitHub Actions primero. Puedes hacerlo en un día.

6. SQL básico: verificar la base de datos por tu cuenta

En algún momento vas a necesitar verificar que lo que muestra la UI realmente se guardó en la base de datos. O ver datos que la UI nunca expone. Eso requiere SQL.

La buena noticia: el SQL de QA no es SQL complejo. Son quizás cinco patrones de consulta que cubren el 80% de lo que vas a necesitar:

-- Verificar si un usuario existe
SELECT * FROM users WHERE email = 'test@example.com';

-- Verificar datos relacionados entre tablas
SELECT orders.id, users.email, orders.status
FROM orders
JOIN users ON orders.user_id = users.id
WHERE orders.status = 'pending';

Dos sentencias SELECT. Un JOIN. Condiciones WHERE. Eso es genuinamente la mayor parte. Los roles que piden "experiencia en SQL" casi siempre piden exactamente esto y no mucho más.

7. Cómo funciona internet

Cada test que escribes envía peticiones a través de una red. Entender qué sucede por debajo te ayuda a leer los mensajes de error correctamente, identificar qué se rompió y seguir lo que los desarrolladores describen cuando algo sale mal.

Qué pasa cuando abres una página

Escribes https://lab.becomeqa.com en el navegador y ocurren cuatro cosas en secuencia:

• Búsqueda DNS. El navegador pregunta "¿cuál es la IP de lab.becomeqa.com?" Recibe algo como 104.21.8.42. Los nombres de dominio son solo alias.
• Conexión TCP. El navegador se conecta a esa IP en el puerto 443, que es el puerto estándar de HTTPS.
• Handshake TLS. El navegador y el servidor verifican identidades y negocian el cifrado. Esta es la S de HTTPS.
• Petición/respuesta HTTP. El navegador envía GET / HTTP/1.1, el servidor devuelve HTML.

Todo en menos de 100ms con una conexión decente.

Por qué importa para el testing

"Connection refused" es un problema diferente a "SSL certificate error", que es diferente a "404 Not Found". Tres puntos distintos en esa cadena. Si no conoces la cadena, todos los errores de red te parecen iguales y la depuración lleva cinco veces más tiempo.

Básicos de HTTP: las peticiones tienen un método (GET lee, POST crea, PUT/PATCH actualiza, DELETE elimina), una ruta, headers y opcionalmente un body. Las respuestas tienen códigos de estado: 200 está bien, 404 es ruta no encontrada, 500 significa que el servidor falló. Cada clic y envío de formulario en un test de Playwright es una de estas peticiones ocurriendo por debajo.

8. Git básico

Git es cómo el código de tests se comparte, versiona y despliega. Lo usas para guardar tus tests, mantenerte sincronizado con los desarrolladores y disparar ejecuciones de CI. No necesitas entender los internos de git. Seis comandos y un archivo de configuración es todo lo que necesitas.

Los seis comandos

git clone <repo-url>            # descargar el proyecto a tu computadora
git pull                        # obtener los últimos cambios del equipo
git checkout -b add-login-tests # crear un branch para tus nuevos tests
git add tests/login.spec.ts     # preparar el archivo que modificaste
git commit -m "add login tests" # guardar un snapshot con un mensaje
git push origin add-login-tests # subir tu branch a GitHub/GitLab

Clonar una vez. Pull antes de empezar cada día. Un branch por funcionalidad. Push cuando termines. Ese es el ciclo.

El archivo .gitignore

Playwright genera carpetas con capturas de pantalla, videos y reportes HTML cuando los tests se ejecutan. Nada de eso pertenece al repositorio. Crea .gitignore en la raíz del proyecto:

node_modules/
playwright-report/
test-results/
.env

Si omites este archivo, subes cientos de megabytes de artefactos de tests. Tus compañeros van a saber quién lo hizo.

Depurar fallos en CI

Los tests pasan en local pero fallan en GitHub Actions. Muy común. Lo primero que revisar:

git log --oneline -5     # ver los últimos 5 commits
git diff main            # ver qué cambió respecto a la rama main

Generalmente es o un archivo que olvidaste agregar con git add, o una versión de dependencia que difiere entre tu computadora y el entorno de CI. El log de git muestra exactamente qué se commiteó y qué no.

9. Agile/Scrum: hablar el idioma del equipo

La habilidad más fácil de la lista. La más ignorada por quienes cambian de carrera. No necesitas una certificación. Necesitas no parecer confundido en tu propio standup.

Lo que realmente importa: qué es un sprint (ciclos de trabajo de dos semanas, generalmente), cómo funcionan los standups (qué hiciste, qué haces hoy, qué te bloquea), qué es una historia de usuario, y qué significa "definición de terminado" desde la perspectiva de QA específicamente, porque es diferente de lo que un desarrollador entiende cuando lo dice.

La mayoría de los equipos usa Jira. La herramienta específica cambia de empresa en empresa. Los conceptos no.

¿Cuánto tiempo lleva esto en la realidad?

Respuesta honesta: cuatro a seis meses de 1 a 2 horas por día lleva a la mayoría de las personas a estar listas para un trabajo de nivel inicial. Eso asume que estás practicando realmente, no solo leyendo.

Meses 1-2

Playwright y fundamentos de JavaScript. Practica en lab.becomeqa.com todos los días. No día por medio. Todos los días.

Mes 3

Testing de API y CI/CD. Ten tus tests ejecutándose en GitHub Actions antes de que termine el mes.

Mes 4

SQL, teoría de HTTP y Git. Estos son más cortos de aprender que el primer bloque. No dejes que eso te tiente a saltarlos.

Meses 5-6

Construye un proyecto de portafolio. Practica explicar tus tests en voz alta para ti mismo o para quien quiera escuchar. Empieza a postularte.

Las personas que tardan más casi siempre tienen el mismo patrón: dos semanas de práctica intensa, luego nada durante seis semanas. La consistencia supera a la intensidad. Una hora aburrida todos los días supera a un fin de semana heroico cada mes.

Preguntas frecuentes

No. La mayoría de los ingenieros de QA automation no tienen títulos de informática. Lo que te consigue trabajo es un repositorio de GitHub con tests bien escritos y la capacidad de explicar qué hacen. Un título no prueba eso. Los tests sí.

Playwright para quien empiece desde cero en 2026. Si te incorporas a una empresa que ya usa Selenium, aprende su configuración. Para aprender desde el principio, Playwright es más rápido de dominar, está mejor documentado y lo mantiene activamente un equipo que se preocupa por él.

Manejable. No estás construyendo aplicaciones. Estás leyendo y escribiendo tests. Es una franja pequeña del lenguaje. La mayoría se siente cómoda en cuatro a seis semanas de práctica diaria.

lab.becomeqa.com, un repositorio de GitHub con tus archivos de tests, automatizando flujos en sitios web públicos. Un portafolio que puedas recorrer en una pantalla compartida durante una entrevista vale más que cualquier certificación que exista.