El Plan de 90 Días para Conseguir tu Primer Trabajo de QA

La mayoría de quienes aprenden QA pasan meses con tutoriales y llegan al día 90 con conceptos pero sin portfolio. Este plan estructura 90 días en torno a entregables concretos: un test funcional con Playwright en la semana 4, una suite de más de 20 tests con GitHub Actions CI en la semana 8, y postulaciones activas en la semana 12.

Días 1–30: Fundamentos

El objetivo del primer mes no es convertirte en experto. Es familiarizarte con el vocabulario y la mentalidad del QA, entender cómo se ven los casos de prueba y los reportes de bugs en un equipo real, y escribir tu primer test funcional con Playwright. Todo en paralelo: conceptos de testing manual en las primeras dos semanas, automatización a partir de la semana tres, para que en el día 30 hayas tocado todo lo que vas a seguir construyendo.

Semana 1: Fundamentos del testing manual

Pasa la primera semana entendiendo cómo se ve el testing estructurado. El resultado principal del trabajo de QA manual es el caso de prueba: un conjunto documentado de pasos, precondiciones, resultados esperados y resultados reales. Escribe cinco casos de prueba para el flujo de login en lab.becomeqa.com a mano, en una hoja de Google Sheets o en Notion. Usa columnas para: ID del caso, Precondición, Pasos, Resultado esperado, Resultado real y Estado.

No hagas los pasos vagos. "Ir a la página de login, ingresar el correo admin@becomeqa.com, ingresar una contraseña incorrecta, hacer clic en Enviar, verificar que el mensaje de error dice 'Credenciales inválidas'" es un caso de prueba. "Verificar que el login funciona" no lo es. La precisión es toda la habilidad.

Una vez escritos los casos de prueba del login, escribe cinco más para la lista de ítems: verificar que los ítems cargan, que el conteo coincide con lo que devuelve la API, que el ordenamiento funciona, que la búsqueda filtra los resultados, que una búsqueda vacía muestra un estado vacío con sentido. Ejecuta cada uno manualmente y registra los bugs que encuentres.

Cuando encuentres un bug (y lo vas a encontrar), redáctalo como reporte formal. Un reporte mínimo tiene título, entorno (navegador, sistema operativo), precondiciones, pasos para reproducir, comportamiento esperado, comportamiento real y severidad. La severidad no es qué tan molesto estás. Crítico significa que la app está rota para todos los usuarios. Mayor significa que una función principal no funciona. Menor significa que algo se ve mal pero no bloquea nada. Trivial significa un error tipográfico.

Semana 2: Fundamentos de Agile y la mentalidad QA en un equipo

El trabajo real de QA ocurre dentro de sprints de Agile. Pasa esta semana aprendiendo cómo encajan los QA en ese proceso. Necesitas entender qué es una historia de usuario y cómo se relacionan los criterios de aceptación con los casos de prueba, qué significa "definición de hecho" y por qué QA es parte de ella, y cómo se ve una revisión de sprint desde la perspectiva del QA.

El ejercicio práctico: toma tres historias de usuario de un tablero público de gestión de proyectos (las plantillas de Trello funcionan, o escribe las tuyas basándote en las funciones de lab.becomeqa.com) y escribe criterios de aceptación para cada una. Luego convierte esos criterios en casos de prueba. Este es el flujo real en un trabajo: llega la historia, escribes los tests antes de que el desarrollo termine, luego verificas cuando el desarrollador dice que está listo.

Lee sobre la diferencia entre verificación (¿construimos la cosa correctamente?) y validación (¿construimos la cosa correcta?). Estos términos aparecen en las entrevistas.

Semanas 3–4: Empieza con Playwright

Instala Node.js (versión LTS) y crea un nuevo proyecto de Playwright con npm init playwright@latest. Elige TypeScript cuando te lo pida. Playwright generará una estructura de carpetas y un test de ejemplo. Ejecuta npx playwright test y observa cómo pasa. Esa estructura (tests/, playwright.config.ts, package.json) es sobre la que vas a construir durante los próximos dos meses.

Tu primer test para escribir desde cero es un test de login contra lab.becomeqa.com:

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

test('el login con credenciales válidas muestra el dashboard', 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();
});

Ejecútalo con npx playwright test --headed para ver cómo el navegador se abre y completa los campos solo. Este es el momento que engancha a la mayoría. Luego escribe dos tests más: uno para credenciales inválidas (verifica que aparece el mensaje de error), uno para cerrar sesión (verifica que el botón de login vuelve a ser visible). Al final de la semana 4 deberías tener entre seis y ocho tests pasando y una idea clara de cómo piensa Playwright sobre las páginas.

Días 31–60: Habilidades de automatización

El segundo mes es donde ocurre el trabajo real. Vas a profundizar en Playwright, aprender estrategias de localizadores, escribir aserciones con confianza, implementar Page Object Model, familiarizarte con Git y GitHub, y alcanzar un objetivo concreto: 20 o más tests reales contra lab.becomeqa.com. Este es el material sobre el que te van a preguntar en entrevistas técnicas.

Semana 5: Localizadores y aserciones

Playwright te da varias formas de encontrar elementos en una página. La jerarquía correcta, de más a menos preferida: getByRole, getByLabel, getByPlaceholder, getByText, getByTestId, y luego selectores CSS como último recurso. El motivo de este orden es la resiliencia. Los localizadores basados en roles y etiquetas siguen funcionando cuando un desarrollador renombra una clase CSS o cambia un div por un section. Los selectores CSS se rompen.

Pasa la semana 5 escribiendo localizadores para cada elemento principal de lab.becomeqa.com usando los métodos preferidos. Usa npx playwright codegen https://lab.becomeqa.com para ver cómo Playwright identifica los elementos mientras haces clic. Luego reescribe a mano cada localizador que genera en el formato preferido. Es un ejercicio de práctica deliberada. La salida del codegen suele usar selectores CSS, y quieres construir el hábito de elegir mejores opciones.

Para las aserciones, practica las variedades "blandas" y "duras". Una aserción dura (expect(locator).toBeVisible()) detiene el test inmediatamente si falla. Una aserción blanda (expect.soft(locator).toBeVisible()) registra el fallo pero continúa el test para detectar más problemas en una sola pasada. Usa aserciones blandas cuando quieres verificar el estado completo de una página de una vez; usa las duras cuando un fallo significa que nada más en el test puede ser confiable.

Semana 6: Page Object Model

A estas alturas tus tests probablemente se están volviendo repetitivos. Cada test que necesita un usuario logueado repite las mismas cuatro líneas. El Page Object Model (POM) elimina esa duplicación y hace que tus tests se lean como documentación.

Crea una carpeta pages/. Empieza con dos archivos: LoginPage.ts e ItemsPage.ts.

// pages/LoginPage.ts
import { Page } from '@playwright/test';

export class LoginPage {
  constructor(private page: Page) {}

  async navigate() {
    await this.page.goto('https://lab.becomeqa.com');
  }

  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();
  }

  async getErrorMessage() {
    return this.page.getByRole('alert').textContent();
  }
}

// pages/ItemsPage.ts
import { Page, Locator } from '@playwright/test';

export class ItemsPage {
  readonly itemRows: Locator;

  constructor(private page: Page) {
    this.itemRows = this.page.getByRole('row');
  }

  async getItemCount() {
    return this.itemRows.count();
  }

  async searchFor(term: string) {
    await this.page.getByPlaceholder('Search').fill(term);
  }
}

Reescribe todos tus tests existentes para usar estas clases. Un test que antes tenía doce líneas de configuración se convierte en cuatro. Y si mañana cambia la etiqueta del botón de login, lo corriges en un solo archivo en lugar de en veinte.

Semana 7: Git y GitHub

Llevas un mes escribiendo código. Ahora necesitas versionarlo correctamente y publicarlo en algún lugar visible. Instala Git si no lo tienes. Crea una cuenta en GitHub. Sube tu proyecto de Playwright como repositorio público.

El flujo de Git que necesitas para trabajar: git status para ver qué cambió, git add para preparar archivos específicos, git commit -m "mensaje" para guardar un snapshot, git push para subir. En esta etapa trabajas solo, así que no necesitas flujos de ramas todavía. Practica de todas formas: crea una rama con git checkout -b add-items-tests, escribe tus tests ahí, haz commit y luego combina con git checkout main && git merge add-items-tests. Así opera cada equipo en el que vas a trabajar.

Escribe un README para tu repositorio. No necesita ser largo. Dile a quien lo lea qué es el proyecto, cómo instalar las dependencias (npm install), cómo ejecutar los tests (npx playwright test), y contra qué sitio están probando. Un README que existe y tiene instrucciones que funcionan ya supera a la mayoría de los portfolios de perfil junior.

Semana 8: 20+ tests y cobertura de API

Esta es la semana de ejecución. Tu objetivo es llegar a 20 o más tests pasando contra lab.becomeqa.com. Suena a mucho. No lo es. Entre los flujos de login, las operaciones CRUD de ítems, la búsqueda, el filtrado y los endpoints de la API, hay fácilmente 40 escenarios que vale la pena probar.

Para los tests de API, Playwright lo tiene integrado. No necesitas herramienta aparte:

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

test('GET /api/items devuelve una lista con los campos requeridos', 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('id');
  expect(items[0]).toHaveProperty('destination');
});

Escribe al menos cinco tests de API: un GET del flujo feliz, un POST que crea un ítem, un DELETE que lo elimina, un test de autenticación (¿qué pasa si llamas a la API sin token?), y uno que valida que la estructura de la respuesta coincide con lo que muestra la UI. Mezcla tus tests de API y de UI en la misma suite. Así están estructurados los proyectos reales.

Días 61–90: Portfolio y búsqueda de trabajo

El tercer mes consiste en convertir todo lo que construiste en algo que te consiga trabajo. Configurarás CI para que tus tests se ejecuten automáticamente, escribirás un README profesional, pulirás tu perfil de LinkedIn y empezarás a postularte. La búsqueda de trabajo y el aprendizaje corren en paralelo. No esperes al día 90 para enviar tu primera postulación.

Semana 9: GitHub Actions CI

Una suite de tests que solo corre en tu computadora vale menos para un reclutador que una que corre en la nube en cada commit. Configura GitHub Actions creando un archivo en .github/workflows/playwright.yml:

name: Playwright Tests

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - name: Install dependencies
        run: npm ci
      - name: Install Playwright browsers
        run: npx playwright install --with-deps
      - name: Run tests
        run: npx playwright test
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: playwright-report
          path: playwright-report/
          retention-days: 30

Sube este archivo. Observa la pestaña Actions en tu repositorio de GitHub. Deberías ver que se activa un workflow y tus tests se ejecutan en un contenedor Linux. Cuando pasen, verás una marca verde junto a tu último commit. Esa marca verde es algo que puedes capturar en pantalla y publicar en LinkedIn. También es evidencia concreta de que entiendes CI, una pregunta que aparece en casi toda entrevista técnica.

Si algunos tests son inestables en CI (pasan localmente pero fallan de forma intermitente en el pipeline), eso es una lección importante en sí misma. Los tests inestables suelen fallar en CI por tiempos: la página carga más lento en una máquina en la nube que en tu computadora. La solución casi siempre es reemplazar esperas fijas (page.waitForTimeout(2000)) con esperas correctas de Playwright (page.waitForSelector, o simplemente confiar en que las aserciones de Playwright esperan solas). Rastrea cada test inestable y corrígelo. Una ejecución de CI con un test rojo inestable es peor que una con 15 tests en lugar de 20.

Semana 10: Pulir el portfolio

Tu repositorio de GitHub necesita tres cosas antes de empezar a postularte: un conteo de tests que valga mencionar (20+), un badge de CI en el README, y documentación que un extraño pueda seguir.

Agrega un badge de CI a tu README copiando la URL del badge desde tu workflow de GitHub Actions. En Markdown se ve así:

![Playwright Tests](https://github.com/TU_USUARIO/TU_REPO/actions/workflows/playwright.yml/badge.svg)

Cuando los tests pasan, este badge se muestra en verde en tu README. Es un detalle pequeño que indica que te importan las buenas prácticas.

Expande tu README para incluir una descripción del proyecto, qué estás probando y por qué (lab.becomeqa.com es una aplicación de práctica para ingenieros QA), una tabla con cada archivo de tests y qué cubre, y cómo ejecutar grupos específicos con npx playwright test --grep @api (agrega etiquetas como @api y @ui a tus tests para habilitar esto). El objetivo es que alguien que nunca vio tu proyecto pueda clonarlo, ejecutarlo y entender qué está mirando en menos de diez minutos.

Semana 11: LinkedIn y CV

Tu perfil de LinkedIn necesita cuatro cosas para atraer la atención de reclutadores de QA: un titular que diga a qué apuntas ("QA Automation Engineer | Playwright | TypeScript"), una sección Acerca de con 3 o 4 oraciones que expliquen tu transición al QA y qué construiste, una sección Destacado con un enlace a tu repositorio de GitHub, y una sección de Habilidades con Playwright, TypeScript, JavaScript, Git, GitHub Actions, API Testing y Agile.

Si vienes de otro campo, no lo ocultes. Preséntalo como un activo. "Mi experiencia en atención al cliente me dio una perspectiva diferente sobre cómo los usuarios reales interactúan con el software" es más interesante que fingir que siempre estuviste en tech.

Para tu CV, incluye el proyecto de portfolio de GitHub como una entrada de experiencia, no como una nota al margen. Escríbelo así: "Framework de Automatización con Playwright (Proyecto Personal): construí una suite de tests con más de 25 tests de UI y API contra una aplicación web real usando TypeScript y Playwright. Configuré pipeline de CI/CD con GitHub Actions. Implementé Page Object Model para facilitar el mantenimiento." Cada palabra ahí es verdadera, específica y mapea directamente a lo que piden las ofertas de trabajo.

Si no tienes experiencia profesional en QA, tu CV tiene dos secciones: el proyecto de portfolio y tu experiencia laboral anterior enmarcada en habilidades transferibles (atención al detalle, orientación a procesos, comunicación, trabajo técnico si aplica). Una página máximo.

Semana 12: Postúlate y sigue adelante

Empieza a postularte antes de sentirte listo. Te sentiste sin preparación en el día 30, en el día 60, y te vas a sentir igual en el día 90. La forma de saber qué te falta es entrar a entrevistas y ver qué te preguntan. Un rechazo después de una entrevista técnica donde no pudiste responder algo sobre fixtures o manejo de datos de prueba te dice exactamente qué estudiar después. Eso vale.

Postúlate a entre 5 y 10 empresas en la semana 12. Prioriza empresas con equipos de QA más pequeños (aprenderás más y tendrás más autonomía), empresas cuyos productos usas (el interés genuino se nota en las entrevistas), y empresas que buscan explícitamente ingenieros de automatización junior, no solo roles de "analista QA" puramente manuales.

Después de cada entrevista, anota cada pregunta que no pudiste responder. Dedica una hora a cada tema al día siguiente. La segunda entrevista siempre sale mejor que la primera, y la tercera mejor que la segunda.

Preguntas frecuentes

Veinte es el mínimo. Entre treinta y cuarenta es sólido. No necesitas más. El punto es demostrar amplitud (tests de UI, tests de API, POM, CI), no volumen. Cinco tests que cubren login, lista de ítems, un endpoint de API y muestran Page Object Model son más impresionantes que cincuenta tests de login copiados y pegados.

La mayoría de los proyectos modernos de Playwright usan TypeScript. No necesitas ser experto. El tipado estático ayuda más de lo que complica. Empieza con TypeScript desde el día uno, deja que tu editor te avise cuando los tipos estén mal, y busca qué significa el error. Así se aprende el 90% de lo que necesitas.

Si tu volumen de postulaciones está por debajo de 30 y llevas menos de cuatro semanas aplicando, es muy pronto para sacar conclusiones. Si ya pasaste las 30 postulaciones sin respuesta, el problema suele estar en el CV o en el perfil de LinkedIn, no en tus habilidades. Pídele a alguien de QA o tech que revise tu CV. Únete a comunidades de QA en LinkedIn y Discord. Las personas en esas comunidades suelen compartir roles abiertos y pueden referirte internamente, lo que evita el filtro del CV por completo.

Nunca en lugar del portfolio. Si tienes tiempo libre en el primer mes mientras los conceptos técnicos son más livianos, leer el temario del ISTQB Foundation Level es útil para el vocabulario. Pero un portfolio funcional en GitHub con CI es evidencia más sólida de tus capacidades que cualquier certificación. Los reclutadores que te digan lo contrario son la excepción.

Sigue postulándote y sigue construyendo. Agrega un segundo proyecto al portfolio. Escribe tests contra una aplicación diferente. Muchos proyectos de código abierto aceptan contribuciones que incluyen tests, lo que te da experiencia colaborativa real. Empieza un blog técnico sencillo documentando lo que aprendiste; incluso dos o tres posts sobre problemas específicos que resolviste indican que puedes comunicar ideas técnicas. El plan de 90 días te lleva a la línea de salida, no a la de llegada. La mayoría consigue su primera oferta de QA entre el mes 4 y el mes 6.