Top 50 Preguntas de Entrevista para QA Engineer en 2026 (Con Respuestas)

Las entrevistas de QA evalúan tres cosas: fundamentos (¿puedes hablar sobre conceptos de testing con claridad?), habilidades técnicas (¿puedes escribir y razonar sobre código de tests?) y juicio (¿puedes tomar la decisión correcta cuando no hay una respuesta obvia?). La diferencia entre una respuesta débil y una sólida suele ser la especificidad, no la profundidad técnica: "pruebo todo con rigor" falla; nombrar los criterios de testing basado en riesgo que realmente usas tiene impacto. Este artículo cubre las preguntas que realmente aparecen en las entrevistas de QA en 2026, agrupadas por tema, con ejemplos de ambas.

Fundamentos de testing

La verificación pregunta "¿estamos construyendo el producto correctamente?" chequeando que el producto coincide con las especificaciones, diseños y requisitos. La validación pregunta "¿estamos construyendo el producto correcto?" chequeando que el producto realmente resuelve el problema del usuario.

Respuesta débil: "La verificación verifica el código, la validación verifica el producto." Es vaga y confunde las dos.

Respuesta sólida: "La verificación es interna: ¿coincide el build con lo que fue especificado? La validación es externa: ¿lo que construimos realmente satisface la necesidad del usuario? Un producto puede pasar la verificación (coincide exactamente con la especificación) y fallar la validación (la especificación estaba equivocada sobre lo que los usuarios necesitan)."

Un escenario de prueba es una descripción de alto nivel de qué probar, como "el usuario puede iniciar sesión con credenciales válidas". Un caso de prueba es la implementación detallada paso a paso: inputs exactos, outputs esperados, precondiciones y postcondiciones.

El smoke testing es un paso superficial por las funcionalidades más críticas después de un build. ¿Arranca la app, pueden los usuarios iniciar sesión, funciona el flujo principal? El objetivo es decidir rápidamente si el build vale la pena seguir probando.

El regression testing verifica que la funcionalidad existente sigue funcionando después de nuevos cambios. Es más amplio y lento, porque proteges lo que ya funcionaba para que el nuevo código no lo rompa.

El testing exploratorio es aprendizaje, diseño de tests y ejecución simultáneos. En vez de seguir un script predefinido, el tester explora la aplicación, usa lo que aprende para guiar dónde mirar después, y se adapta en tiempo real. Es valioso para encontrar bugs que los tests con script no cubren porque nadie pensó en escribir un caso de prueba para ellos.

El testing de caja negra trata al sistema como una caja negra: solo conoces los inputs y los outputs esperados, no la implementación interna. El testing de caja blanca usa el conocimiento del código interno, así que escribes tests basados en rutas de código, branches y lógica.

La mayoría de los QA engineers hace testing de caja negra. El conocimiento de caja blanca es útil para entender qué casos extremos probar.

Diseño de tests

Testing basado en riesgo: prioriza por probabilidad de fallo e impacto del fallo. Un flujo de pago fallando es de alto impacto. Una "tooltip al pasar el cursor" fallando es de bajo impacto. Una funcionalidad nueva tiene mayor probabilidad de fallo que una estable que no cambió en meses.

Respuesta débil: "Pruebo todo con rigor." Nadie prueba todo. El tiempo y los pipelines de build no lo permiten.

Respuesta sólida: "Empiezo por entender qué cambió y qué tiene mayor riesgo. El código nuevo recibe más cobertura que el código sin cambios. Los flujos que ve el usuario reciben más cobertura que los que solo ven los administradores. También hablaría con el desarrollador para entender qué casos extremos le generan más incertidumbre."

La partición de equivalencia divide el espacio de input en grupos donde todos los valores del grupo se comportan de la misma manera. En vez de probar cada edad posible, pruebas un valor de cada partición: menor de 18, entre 18 y 65, mayor de 65.

El análisis de valores límite prueba los extremos de esas particiones (17, 18, 65, 66) porque los bugs se agrupan en los límites. El código que maneja "18–65" correctamente a menudo tiene un error de uno en exactamente 18 o 65.

Una respuesta sólida incluye: camino feliz (credenciales válidas → éxito), caminos negativos (contraseña incorrecta, usuario incorrecto, campos vacíos, intento de inyección SQL, inputs muy largos), casos límite (longitud mínima/máxima de campo) y consideraciones no funcionales (qué pasa si el botón de enviar se hace clic dos veces).

Título (conciso, describe el problema), entorno (navegador, SO, versión de la app), pasos para reproducir (exactos, numerados), resultado esperado, resultado actual, severidad/prioridad, y adjuntos (captura de pantalla, video, logs de red si son relevantes).

Automatización

Automatiza cuando: el test se ejecuta con frecuencia (regresión), los datos del test son consistentes, el escenario es estable (no va a cambiar cada sprint), y la automatización va a ahorrar más tiempo del que cuesta construir y mantener.

No automatices cuando: el test requiere juicio humano (usabilidad, diseño visual), la funcionalidad cambia cada sprint y los tests tendrían que reescribirse constantemente, o el test se ejecuta una vez y se descarta (verificación de migración de datos de una sola vez).

POM es un patrón de diseño que envuelve las interacciones de página en una clase. En vez de llamar page.getByLabel('Username').fill(email) en cada test, creas una clase LoginPage con un método login(email, password). Los tests llaman al método; cuando el formulario de login cambia, lo corriges en un solo lugar.

Tests unitarios en la base: muchos, rápidos, baratos de escribir y ejecutar. Prueban funciones y componentes individuales. Tests de integración en el medio: menos, prueban las interacciones entre componentes. Tests end-to-end en la cima: los menos, los más lentos, prueban flujos completos de usuario a través de la UI.

La forma de pirámide importa. Invertirla (principalmente tests E2E) te da feedback lento, alto costo de mantenimiento y suites flaky.

Los tests flaky fallan aleatoriamente en el mismo código. Causas comunes: problemas de timing (el elemento no está listo cuando el test actúa sobre él), contaminación de tests (estado que se filtra entre tests), conflictos de ejecución en paralelo (dos tests modificando los mismos datos simultáneamente).

Corrección: para timing, usa esperas correctas (espera condiciones específicas, no retrasos fijos). Para contaminación, asegúrate de que cada test configure y limpie su propio estado. Para conflictos en paralelo, usa datos de prueba únicos por test o ejecuta los tests en conflicto de forma serial.

Específico de Playwright

Cada acción de Playwright espera automáticamente a que el elemento objetivo alcance un estado "accionable" antes de proceder. Para click(): el elemento debe ser visible, estable y habilitado. Para fill(): el elemento debe ser editable. Esta espera ocurre automáticamente con un timeout configurable (por defecto 30 segundos).

Usa storageState. Inicia sesión una vez en un archivo de setup, guarda las cookies de auth del navegador y el localStorage en un archivo JSON, luego configura cada test para cargar ese estado:

// Setup global: inicia sesión y guarda el estado de auth
await page.context().storageState({ path: 'auth.json' });

// playwright.config.ts
use: {
  storageState: 'auth.json'
}

Cada test arranca ya autenticado sin pasar por la UI de login.

Agile y proceso

El QA debe involucrarse desde el principio: revisar requisitos y criterios de aceptación durante la planificación, hacer preguntas de aclaración durante el refinement, escribir o revisar casos de prueba antes de que empiece el desarrollo. El testing no debería comenzar solo cuando el desarrollo está "listo". Eso crea un cuello de botella al final del sprint.

Mover las actividades de testing más temprano en el proceso de desarrollo. En vez de probar después de que el código está completo, revisas los requisitos por testeabilidad, escribes casos de prueba durante el desarrollo y ejecutas tests como parte del proceso de build. El objetivo es encontrar defectos antes, cuando son más baratos de corregir.

Presenta evidencia: pasos exactos de reproducción, comportamiento esperado según los requisitos o el diseño, y el comportamiento real. Si es genuinamente ambiguo (no está en la especificación), escala al product owner quien puede decidir si el comportamiento actual es aceptable. No argumentes. Documenta.

Evalúa el impacto: ¿a quién afecta, con qué frecuencia ocurre, hay una solución alternativa? Escala inmediatamente al team lead y al product owner con la evaluación de impacto. No retengas el release en silencio. La decisión de lanzar, retrasar o hacer un hotfix le corresponde al product owner, no al QA. Tu trabajo es visibilizar el riesgo de forma clara y rápida.

Carrera y situacionales

El QA Engineer se enfoca en la estrategia de testing, la ejecución de tests y el proceso de calidad. El SDET (Software Development Engineer in Test) es un rol con más componente de ingeniería: construir frameworks de tests, infraestructura de tests, pipelines de CI/CD y herramientas de testing. Los SDETs escriben código de calidad de producción para sistemas de testing, no solo scripts de tests.

En la práctica, los títulos se superponen y las empresas los usan de forma diferente. Mira la descripción del puesto, no el título.

Estructúralo con STAR: Situación (qué se estaba lanzando), Tarea (tu rol), Acción (cómo lo encontraste, qué hiciste), Resultado (qué pasó). Sé específico: números, plazos, impacto real. "Encontré un bug que habría afectado a todos los usuarios de checkout y retrasamos el lanzamiento para corregirlo" es mejor que "encontré un bug importante una vez."

Nombra cosas específicas: blogs que lees (Ministry of Testing, changelog de Playwright), conferencias (TestBash), newsletters, cursos que completaste. "Leo artículos online" es una respuesta débil. Las fuentes y ejemplos específicos son sólidos.