La mayoría de los QA engineers que compiten por roles de automatización no tiene código público para mostrar, así que el hiring engineer que revisa su solicitud lee texto sobre experiencia en testing y toma una decisión subjetiva. Un repositorio de GitHub con un pipeline de CI pasando cuenta la misma historia en 30 segundos sin requerir ninguna inferencia. Este artículo cubre exactamente qué poner en un portafolio de QA: la estructura de la suite de Playwright, la organización de directorios, el README, y el error que convierte un portafolio en un pasivo.
Por qué importa un portafolio para roles de QA
La automatización de QA es una habilidad técnica. Las empresas que contratan para ello quieren ver código, no descripciones de código.
Un CV que dice "5 años de experiencia con Playwright y TypeScript" y un portafolio que muestra 5 años de experiencia con Playwright y TypeScript producen resultados diferentes en la etapa de screening de solicitudes.
El hiring engineer que revisa tu solicitud tiene 30 a 60 segundos antes de decidir si seguir leyendo o pasar al siguiente. Un link a un repositorio de GitHub con código de tests limpio y bien estructurado hace más trabajo en esos 30 segundos que un párrafo de texto.
La barrera es más baja de lo que parece. La mayoría de los QA engineers no tiene portafolios públicos. Aparecer con uno te pone en una categoría diferente de inmediato.
Qué poner en un portafolio de QA
No necesitas un proyecto masivo. Necesitas evidencia de competencias específicas. Cada elemento de tu portafolio debería demostrar algo concreto.
Una suite de tests de Playwright contra una aplicación real
Esta es la pieza central. Un repositorio con tests para una aplicación real: no una app de tutorial, no localhost, sino un sitio web público accesible.
Qué probar: el entorno de práctica de BecomeQA en lab.becomeqa.com existe específicamente para esto. Es una aplicación React con login, operaciones CRUD, carga de archivos y una sección de pago. Escribe tests contra ella.
Qué debería incluir la suite:
- Flujo de login (camino feliz + casos negativos)
- Operaciones CRUD para la funcionalidad principal (añadir ítem, editar ítem, eliminar ítem)
- Tests de validación de formularios
- Al menos un test de API usando el fixture
requestde Playwright - Estructura de Page Object Model
Tamaño mínimo viable: 15 a 20 tests que realmente pasen. Calidad sobre cantidad.
Estructura de directorios que refleja conocimiento real
my-playwright-tests/
├── playwright.config.ts
├── package.json
├── tests/
│ ├── auth/
│ │ ├── login.spec.ts
│ │ └── logout.spec.ts
│ └── items/
│ ├── create-item.spec.ts
│ ├── edit-item.spec.ts
│ └── delete-item.spec.ts
├── pages/
│ ├── BasePage.ts
│ ├── LoginPage.ts
│ └── ItemsPage.ts
└── utils/
└── testHelpers.tsEsta estructura muestra que entiendes el Page Object Model, la organización de tests y la separación de la lógica de tests de la lógica de página. Un directorio plano con 20 archivos .spec.ts en la raíz muestra lo contrario.
Un README que explica qué construiste
Escribe un README que cubra:
1. Qué hace la suite de pruebas (qué aplicación, qué escenarios)
2. Cómo ejecutarla (npm install && npx playwright test)
3. Qué tecnologías se usan (Playwright, TypeScript, patrón POM)
4. Qué añadirías después (muestra que puedes pensar en alcance y prioridades)
Mantenlo corto: 200 a 400 palabras. El README lo leen los hiring engineers para decidir si mirar el código.
Qué hace que el código del portafolio se destaque
Usa locators semánticos
Tests que usan page.getByRole('button', { name: 'Submit' }) y page.getByLabel('Email') muestran comprensión de accesibilidad y buenas prácticas de locators. Tests que usan page.locator('div.modal-body > form > button:nth-child(2)') muestran lo contrario.
Tiene aserciones significativas
No solo "la página existe" sino resultados específicos verificables:
// Débil
await expect(page).toHaveURL('/dashboard');
// Sólido
await expect(page.getByRole('heading', { name: 'My Travel Items' })).toBeVisible();
await expect(page.getByRole('navigation')).toContainText('admin@becomeqa.com');Sin llamadas a waitForTimeout
Cada await page.waitForTimeout(2000) en tu portafolio es una señal de que no entiendes el auto-waiting. Reemplázalos con web-first assertions.
Nombres consistentes
Los nombres de los tests describen el escenario: 'el usuario puede iniciar sesión con credenciales válidas', no 'test de login'. Los nombres de archivos describen la funcionalidad: login.spec.ts, no test1.spec.ts.
TypeScript con tipos usados correctamente
Si afirmas experiencia en TypeScript, tu código debería usar tipos: page objects tipados, helpers tipados, sin any por todos lados.
Configurar el repositorio del portafolio
# Inicializar un nuevo proyecto
mkdir my-playwright-portfolio
cd my-playwright-portfolio
npm init playwright@latest
# Elegí TypeScript cuando te lo pregunte
# Seleccioná tests/ como directorio de tests
# Sí al workflow de GitHub ActionsEsto te da una configuración de Playwright funcionando con TypeScript y un archivo de workflow de GitHub Actions que ejecuta tus tests en CI.
Añadir los tests
// tests/auth/login.spec.ts
import { test, expect } from '@playwright/test';
import { LoginPage } from '../../pages/LoginPage';
test.describe('Login', () => {
test('el usuario puede iniciar sesión con credenciales válidas', async ({ page }) => {
const loginPage = new LoginPage(page);
await loginPage.goto();
await loginPage.login('admin@becomeqa.com', 'testpass123');
await expect(page.getByRole('heading', { name: 'My Travel Items' })).toBeVisible();
});
test('muestra error con contraseña incorrecta', async ({ page }) => {
const loginPage = new LoginPage(page);
await loginPage.goto();
await loginPage.login('admin@becomeqa.com', 'wrongpassword');
await expect(page.getByText('Invalid credentials')).toBeVisible();
await expect(page).not.toHaveURL('/dashboard');
});
});Subir a GitHub con CI pasando
El workflow de GitHub Actions que crea npm init playwright@latest ejecuta tus tests automáticamente en cada push. Tener un pipeline de CI pasando impresiona más que tener tests que "funcionan en mi máquina".
Revisa tu pestaña Actions después de hacer push. Si los tests pasan: tu portafolio muestra un pipeline de CI en vivo ejecutando tests de Playwright. Eso vale más que cualquier cosa que puedas escribir en un CV.
Si fallan: corrígelos antes de compartir el link.
Qué más incluir
Reportes de bugs de muestra
Una colección de 3 a 5 reportes de bugs bien escritos. No tienen que ser de una empresa. Pueden ser bugs que encuentras en cualquier aplicación pública, incluyendo lab.becomeqa.com.
Formatéalos exactamente como la plantilla de La Anatomía de un Bug Report que los Desarrolladores Realmente Arreglan: título, entorno, precondiciones, pasos, resultado esperado, resultado actual, severidad, adjuntos.
Ponlos en una carpeta /bug-reports como archivos markdown. Demuestra habilidades de comunicación escrita y reporte de bugs que los tests automatizados no muestran.
Documento de plan de pruebas o casos de prueba
Un documento corto que muestre cómo enfocarías el testing de una funcionalidad desde cero. Elige una funcionalidad específica (la carga de archivos en lab.becomeqa.com, por ejemplo) y escribe los escenarios de prueba que cubrirías, por qué elegiste esos escenarios, y qué priorizarías y por qué.
Demuestra pensamiento estratégico de testing, no solo ejecución.
Dónde compartir tu portafolio
Perfil de LinkedIn
Añade el link al repositorio de GitHub en tu sección "Destacado". Escribe una descripción de 2 oraciones: qué es y qué demuestra.
CV o currículum
Un link directo al repositorio en la sección "Proyectos". El link hace más trabajo que las descripciones.
Solicitudes de empleo
Cuando te pidan "portafolio o ejemplos de código," enlaza directamente al repositorio, no a tu perfil general de GitHub.
README del perfil de GitHub
Si configuras un README de perfil de GitHub (el repositorio usuario/usuario), aparece en tu perfil de GitHub. Menciona ahí tu portafolio de QA.
Errores comunes a evitar
Testear localhost
Los tests contra http://localhost:3000 no corren para nadie que revise tu portafolio. Prueba contra una URL pública.
Commitear datos sensibles
Nunca commites credenciales reales. Usa variables de entorno para los datos de prueba:
// Mal
await page.fill('#email', 'admin@becomeqa.com');
// Mejor (aunque para un portafolio, credenciales hardcodeadas de una app de pruebas son aceptables)
await page.fill('#email', process.env.TEST_EMAIL || 'admin@becomeqa.com');Tests que no pasan
Si tu GitHub Actions está fallando, corrígelo antes de compartir. Un pipeline de CI fallando es peor que no tener pipeline.
Sin README
Un repositorio sin explicación obliga al revisor a inferir qué construiste y por qué. La mayoría no se va a molestar.
Tutoriales copiados sin modificación
Si tus tests son casi idénticos a un tutorial que seguiste, adáptalos. Añade tests que el tutorial no incluía. Cambia la aplicación que se prueba. Muestra que puedes aplicar lo que aprendiste, no solo copiarlo.
Preguntas frecuentes
No tengo trabajo real de automatización para mostrar. ¿Qué hago?Construye un portafolio usando entornos de prueba públicos. lab.becomeqa.com existe para esto. Otras opciones: the-internet.herokuapp.com, automationexercise.com, saucedemo.com. La aplicación no importa. La calidad del código sí.
Un portafolio mínimo viable (15 a 20 tests, estructura POM, CI pasando, README) lleva entre 15 y 25 horas de trabajo enfocado para alguien que conoce Playwright. Si todavía estás aprendiendo, presupuesta entre 30 y 40 horas distribuidas en algunas semanas.
¿Debería incluir ejemplos de tests de API?Sí, si los tienes. Uno o dos tests de API usando el fixture request de Playwright muestran que entiendes el stack completo de testing:
test('API: crear ítem devuelve 201', async ({ request }) => {
const response = await request.post('/api/items', {
data: { destination: 'Tokio', status: 'Planned' },
headers: { Authorization: `Bearer ${token}` },
});
expect(response.status()).toBe(201);
});Sí, notablemente. Los QA engineers sin portafolio compiten con texto de CV. Los QA engineers con portafolio le dan a los hiring engineers algo concreto para evaluar. En la práctica, quienes tienen portafolio avanzan más lejos en el proceso de screening en empresas técnicas.
→ See also: Roadmap de Automatización QA 2026: Habilidades Esenciales para Conseguir Trabajo
