Las entrevistas técnicas de QA tienen cuatro rondas distintas, y los candidatos fallan en cada una por razones diferentes: el filtro técnico tropieza con vacíos en conceptos de testing, la ronda de código en vivo es donde congelarse bajo observación es la trampa principal, y la ronda conductual es donde las respuestas vagas sobre experiencia pasada hacen perder puntos. La ronda de código en vivo es la que más elimina. Conocer Playwright conceptualmente no te prepara para escribir un test mientras alguien te mira. Esta guía mapea un plan de preparación de 2 a 4 semanas para cada ronda, con ejercicios específicos, los temas más evaluados en niveles junior y mid, y qué están calificando realmente los entrevistadores.
Qué cubren realmente las entrevistas técnicas de QA
Antes de prepararte, entiende el formato. Las entrevistas técnicas de QA en 2026 generalmente consisten en:
| Ronda | Qué se evalúa | Duración |
|-------|--------------|----------|
| Filtro de recruiter | Background, motivación, básicos | 20–30 min |
| Filtro técnico | Conceptos de QA, herramientas, experiencia | 45–60 min |
| Código en vivo / automatización | Escribir tests de Playwright, depuración | 45–60 min |
| Diseño de sistema (roles senior) | Estrategia de testing, arquitectura | 45–60 min |
| Conductual | Experiencia pasada, habilidades blandas | 30–45 min |
No todas las empresas hacen todas estas rondas. Las más pequeñas suelen combinarlas. Pero conocer las categorías ayuda a distribuir el tiempo de preparación.
Paso 1: Saber qué nivel estás apuntando (semana 1)
La profundidad de las preguntas técnicas escala con la seniority. Antes de estudiar, sé honesto sobre qué nivel te corresponde.
Foco de la entrevista junior
- Playwright básico: locators, aserciones, estructura básica de tests
- Fundamentos de reporte de bugs
- Comprensión de tipos de testing (smoke, regression, sanity)
- Básicos de Agile
- Testing manual: qué es, por qué y cuándo
Foco de la entrevista mid-level
- Todo lo anterior, con más profundidad
- Testing de API: códigos de estado, request/response, API de request de Playwright
- Diseño de tests: partición de equivalencia, análisis de valores límite
- CI/CD: GitHub Actions, pipelines de test
- Page Object Model
Foco de la entrevista senior
- Estrategia de testing y decisiones de arquitectura
- Construcción y mantenimiento de frameworks de automatización
- Testing basado en riesgo y priorización bajo restricciones
- Influencia en el equipo y mejora de procesos
- Conocimiento de testing de performance y seguridad
Paso 2: Mapear tus vacíos (semana 1)
Haz un inventario honesto. Marca cada punto como: seguro / dudoso / no sé.
Playwright
- Configurar un nuevo proyecto de Playwright
- Locators: getByRole, getByTestId, getByLabel, getByText
- Aserciones: toBeVisible, toHaveText, toContainText, toHaveValue
- test.beforeEach y test.afterEach
- Fixtures: usar los integrados, crear custom
- Patrón Page Object Model
- Testing de API con el fixture request
- Interceptación de red con route.fulfill
- Ejecutar tests en modo headed/headless
- Leer e interpretar el reporte HTML
Conceptos de testing
- Partición de equivalencia y análisis de valores límite
- Testing de caja negra vs. caja blanca
- Testing smoke, regression, sanity: diferencias
- La pirámide de testing y dónde encaja cada tipo
- Testing basado en riesgo y priorización
- Testing shift-left
- Definición de Done desde la perspectiva de QA
API y web
- Métodos HTTP (GET, POST, PUT, PATCH, DELETE)
- Códigos de estado (200, 201, 400, 401, 403, 404, 422, 500)
- Estructura de un request: headers, body, query params
- Qué es un token JWT
- Cómo funcionan las cookies del navegador
Todo lo que marcaste como "dudoso" o "no sé" es tu lista de estudio.
Paso 3: Estudiar las cosas correctas (semanas 1–2)
Fundamentos de Playwright
No solo leas sobre él: escribe código. Configura un proyecto de práctica:
npm init playwright@latestElige un sitio de práctica público (lab.becomeqa.com, the-internet.herokuapp.com, automationpractice.pl) y escribe tests para:
- Formulario de login (credenciales válidas e inválidas)
- Un formulario con múltiples campos y validación
- Una tabla: verificar datos, ordenar, filtrar
- Un endpoint de API usando
request
Si escribes 5 a 10 tests de Playwright desde cero en un sitio real, ya estás por delante de la mayoría de los candidatos.
Reporte de bugs
Tienes que estar listo para escribir un bug report en el momento. Practica escribir:
- Título claro (no "el login no funciona", sino "El botón de login no responde cuando el email contiene letras mayúsculas")
- Pasos para reproducir (numerados, exactos)
- Comportamiento esperado vs. comportamiento actual
- Entorno (navegador, sistema operativo, versión)
- Severidad y prioridad
Diseño de tests
Conocé al menos un ejemplo de aplicación de partición de equivalencia y análisis de valores límite. El ejemplo del campo de edad (0, 1, 17, 18, 120, 121) es bueno para internalizar.
Vocabulario de teoría de testing
Puedes explicar con claridad (sin definiciones memorizadas):
- ¿Qué es el testing de regresión?
- Diferencia entre severidad y prioridad
- ¿Qué es un caso de prueba vs. un escenario de prueba?
- ¿Qué es el testing shift-left?
- ¿Qué significa "test inestable" y por qué ocurre?
Paso 4: Practicar la ronda de código en vivo (semanas 2–3)
Acá es donde la mayoría pierde puntos. Conocen Playwright conceptualmente pero se congelan cuando tienen que escribir un test en tiempo real.
Practica en voz alta. Cuando escribes un test, narra: "Voy a ubicar el campo de email por su test ID...", "Estoy haciendo la aserción de que el mensaje de error es visible..." y "También debería manejar el caso donde el login tiene éxito y verificar la redirección..."Los entrevistadores valoran el razonamiento, no solo el resultado.
Escenarios comunes de código en vivo
1. Escribir un test de Playwright para un formulario de login
2. Escribir un test que llame a una API y verifique la respuesta
3. Depurar un test fallido (te muestran código con un bug)
4. Agregar un test para un caso límite específico que describen
Qué hacer cuando estás trabado
Si no conoces la sintaxis exacta, di "No estoy 100% seguro de la sintaxis exacta acá, pero el enfoque sería..." o "Necesitaría verificar los docs de Playwright para esta aserción específica, pero sé que existe...". Admitir incertidumbre con gracia es mucho mejor que adivinar mal y defenderlo.
Paso 5: Preparar tus historias (semana 3)
Las preguntas conductuales necesitan ejemplos concretos. Antes de la entrevista, escribí notas breves para:
1. Un bug crítico que encontraste antes de un release
2. Una vez que no estuviste de acuerdo con un desarrollador sobre un bug (y lo resolviste profesionalmente)
3. Una vez que tuviste que testear bajo presión de tiempo: qué priorizaste
4. Una mejora de proceso que introdujiste o sugeriste
5. Un bug que llegó a producción sin ser detectado (y qué aprendiste)
Si no tenés 5 años de experiencia, podés usar proyectos académicos, proyectos personales o situaciones muy junior. Lo que importa es la especificidad, no la seniority.
Paso 6: Investigar la empresa (semanas 3–4)
Las respuestas genéricas obtienen resultados genéricos. Para cada empresa:
- ¿Qué hace su producto? (Úsalo antes de la entrevista)
- ¿Qué stack tecnológico menciona la oferta?
- ¿Se enfocan en web, mobile, API, performance?
- ¿Qué dice su blog de ingeniería o su LinkedIn sobre su proceso?
Adaptar aunque sea una o dos respuestas al contexto de la empresa demuestra compromiso real.
El día de la entrevista
Filtro técnico: consejos de comunicación
- Piensa en voz alta. El silencio es peor que el pensamiento imperfecto.
- Haz preguntas aclaratorias: "¿Debo asumir que el usuario ya está logueado?" "¿Estamos testeando esto de forma aislada o end-to-end?"
- Si no sabes, dilo y explica qué harías para encontrar la respuesta.
- Al terminar una respuesta, agrega: "¿Hay algo específico sobre esto en lo que quieras que profundice?"
Código en vivo: consejos de configuración
Si puedes usar tu propio editor, ten un proyecto de Playwright ya configurado con un archivo de test en blanco listo. Si necesitas escribir en un editor compartido, di "voy a empezar con el esqueleto del test y completar los locators". Mantén las aserciones claras y deliberadas: nombra qué estás verificando y por qué.
Preguntas para hacerle al entrevistador
Estas señalan pensamiento estratégico, no solo conocimiento técnico:
- "¿Cómo maneja el equipo de QA actualmente el testing de regresión: automatizado, manual, o ambos?"
- "¿Cuál es el mayor desafío de calidad que enfrenta el equipo en este momento?"
- "¿Cómo colaboran los ingenieros QA con los desarrolladores? ¿El testing está integrado en la definición de Done?"
- "¿Cómo se ve la pirámide de tests para su producto?"
Qué buscan realmente los entrevistadores
Más allá de las preguntas técnicas, los entrevistadores evalúan:
Enfoque de resolución de problemas
¿Puedes descomponer un problema de testing sistemáticamente, o saltas directamente a soluciones?
Comunicación
¿Explicas tu razonamiento con claridad? ¿Puedes hablar de un bug report de una forma que un desarrollador encuentre útil?
Mentalidad de calidad
¿Piensas en los casos límite de forma natural? ¿Preguntas "¿y si el usuario hace X?" por tu cuenta?
Señales de colaboración
Cuando describes experiencia pasada, ¿mencionas compañeros de equipo, acuerdos, comunicación? ¿O todo es "yo hice esto solo"?
Trayectoria de crecimiento
¿Fuiste intencional en tu aprendizaje? ¿Puedes nombrar una habilidad que hayas desarrollado activamente en los últimos tiempos?
Cronograma de 4 semanas
| Semana | Foco |
|--------|------|
| 1 | Evaluar vacíos, repasar Playwright básico, escribir 3–5 tests de práctica |
| 2 | Estudio profundo en áreas débiles, practicar explicar conceptos en voz alta |
| 3 | Práctica de código en vivo, preparar historias conductuales, investigar empresas |
| 4 | Entrevistas simuladas, repaso, refuerzo puntual de áreas dudosas |
→ See also: Top 50 Preguntas de Entrevista para QA Engineer en 2026 (Con Respuestas) | Top 30 Preguntas de Entrevista sobre Playwright para 2026 | Preguntas Conductuales para Entrevistas QA: Cómo Responderlas Bien