La pregunta que más ansiedad genera antes de una entrevista técnica QA no es "¿qué me van a preguntar?". Es "¿voy a quedar en ridículo si no sé programar?".
La respuesta corta es que no, si el puesto es junior. La mayoría de entrevistas técnicas QA en España para nivel junior giran en torno a fundamentos, criterio y cómo piensas, no alrededor de si dominas un framework de automatización.
Aquí tienes las preguntas que de verdad se repiten, agrupadas por bloque, con lo que distingue una buena respuesta de una memorizada.
Cómo está montada una entrevista técnica QA en España
El proceso más habitual para un puesto QA junior tiene dos fases: una entrevista con Recursos Humanos (perfil, motivación, expectativas salariales) y una entrevista técnica con alguien del equipo de QA o desarrollo. Algunas empresas añaden una prueba práctica corta, como diseñar casos de prueba sobre una funcionalidad dada, antes o en lugar de esa segunda fase.
La entrevista técnica en sí suele repartirse en tres bloques. Ninguno exige automatización de nivel senior, pero sí que entiendas por qué haces lo que haces, no solo el "cómo".
Conceptos base del testing: tipos de prueba, verificación vs validación, ciclo de vida del software.
Cómo aplicas la teoría: diseño de casos, bug reports, herramientas del día a día.
Cómo trabajas en equipo y gestionas conflicto o presión.
Fundamentos que siempre caen: verificación vs validación
Es la pregunta de fundamentos más repetida en entrevistas QA, en España y fuera. También es la que peor se responde, porque la mayoría de candidatos la memoriza sin entenderla.
Verificación responde a "¿estoy construyendo el producto correctamente?". Validación responde a "¿estoy construyendo el producto correcto?". La primera se hace sin ejecutar el software (revisiones de requisitos, de diseño), la segunda sí lo ejecuta.
- "Verificación es estoy construyendo el producto correctamente."
- "Validación es estoy construyendo el producto correcto."
- (silencio cuando piden un ejemplo)
"Verificar es revisar el documento de requisitos de un formulario de registro antes de programarlo. Validar es probar ese formulario ya construido y comprobar que un usuario real consigue registrarse sin problemas."
Esa misma lógica (explica con un ejemplo propio) se aplica a cualquier pregunta de fundamentos: tipos de testing (funcional, no funcional, regresión, smoke, exploratorio), niveles de prueba (unitario, integración, sistema, aceptación) o qué es el STLC. Nombrar el concepto suma poco, aplicarlo a un caso concreto es lo que distingue a quien lo entiende de quien lo recitó la noche anterior.
Preguntas sobre casos de prueba y cómo decides qué probar
Ya hemos cubierto a fondo cómo se diseñan casos de prueba con partición de equivalencia, valores límite y tablas de decisión, así que aquí solo lo que cambia de contexto en la entrevista.
No basta con nombrar la técnica. Te van a pedir que la apliques ahí mismo sobre un ejemplo que te propongan: un formulario de registro, un carrito de compra, un campo de descuento. Y casi siempre te van a preguntar también qué diferencia hay entre un caso de prueba y un caso de uso.
Si no recuerdas el nombre exacto de una técnica pero sabes explicar la idea, dilo con tus palabras. Un entrevistador que sabe de QA prefiere mil veces a alguien que razona "probaría el valor justo en el límite del descuento" sobre alguien que suelta "valores límite" y se queda callado cuando le piden que lo aplique.
Preguntas sobre bugs: reportarlos y priorizarlos
Junto a los casos de prueba, es el otro bloque práctico que casi nunca falta. Puedes repasar cómo escribir un bug report efectivo con los campos que hacen que un bug se solucione en vez de rebotarse.
La pregunta trampa habitual es pedirte que ordenes una lista de tres o cuatro bugs por prioridad. No hay una única respuesta correcta: lo que se evalúa es que distingas severidad (cuánto rompe el bug) de prioridad (cuánto urge arreglarlo), porque no siempre van de la mano.
| Severidad | Prioridad | Qué hacer |
|---|---|---|
| Alta | Alta | Arreglar ya (el pago no funciona) |
| Alta | Baja | Arreglar pronto (crash en una función que casi nadie usa) |
| Baja | Alta | Arreglar pronto (logo mal en la campaña de hoy) |
| Baja | Baja | Puede esperar (un typo en un tooltip) |
Preguntas sobre herramientas: lo que se espera que sepas manejar
Aquí es donde más candidatos junior se ponen nerviosos sin necesidad. El listón real para un puesto de entrada es más bajo de lo que parece en las ofertas de empleo, que suelen listar todo lo que usa el equipo, no solo lo imprescindible para entrar.
| Herramienta | Nivel junior | Nivel semi-senior |
|---|---|---|
| Jira o similar | Imprescindible crear y clasificar tickets | Configurar workflows y dashboards |
| Postman | Imprescindible probar un endpoint, leer códigos de estado | Automatizar colecciones con Newman |
| Playwright, Cypress o Selenium | Valorado saber para qué sirve cada uno | Imprescindible escribir y mantener suites |
| Git | Valorado clonar, commit, pull request básico | Resolver conflictos, gestionar ramas |
Para entender qué hace cada herramienta de automatización antes de la entrevista, la comparativa de Playwright vs Cypress vs Selenium explica las diferencias reales, y la guía de cómo testear una API REST con Postman cubre justo lo que se espera a nivel junior.
Si el puesto es junior y no dominas automatización, dilo con seguridad en vez de improvisar. "Todavía no he automatizado en un entorno real, pero entiendo la diferencia entre Playwright, Cypress y Selenium y sé qué elegiría según el caso" vale más que fingir experiencia que no tienes, porque se nota en la primera pregunta de seguimiento.
Preguntas de comportamiento: el método STAR
El bloque de comportamiento busca respuestas concretas, no generalidades. Preguntas típicas: "cuéntame de un bug que encontraste que nadie más había visto" o "describe un desacuerdo con un desarrollador sobre si algo era un bug".
El método STAR estructura la respuesta en cuatro pasos, y evita que te quedes en un "suelo trabajar bien en equipo" sin contenido real detrás:
- Situación. El contexto concreto: qué proyecto, qué momento, qué problema había.
- Tarea. Qué se esperaba de ti en concreto en esa situación.
- Acción. Qué hiciste tú, en primera persona, no lo que hizo el equipo.
- Resultado. Qué pasó al final, con un dato o consecuencia concreta si puedes darlo.
Errores que descalifican a un candidato junior
Ninguno de estos errores tiene que ver con no saber lo suficiente. Tienen que ver con cómo se gestiona lo que no se sabe, que es justo lo que un entrevistador puede evaluar en 30 minutos.
- Memorizar definiciones sin ejemplo propio. Se nota en la primera pregunta de seguimiento.
- Tratar la falta de experiencia en automatización como vergonzosa. Mostrar interés por aprenderla pesa más que fingir que ya la dominas.
- Inventar experiencia con una herramienta que no conoces. El riesgo de que te pidan un detalle concreto es alto, y ahí se cae la respuesta entera.
- No preguntar nada al final de la entrevista. Da la sensación de que no te has parado a pensar en el puesto o el equipo.
Lo honesto es decir que ninguna de estas preguntas tiene trampa real. Buscan candidatos que entienden lo que hacen y lo explican con sus propias palabras, no candidatos que ya llegan sabiéndolo todo. Para eso está justamente el nivel junior.
Preguntas frecuentes
¿Qué diferencia hay entre verificación y validación?
Verificación comprueba que el producto se construye conforme a lo especificado (requisitos, diseño), sin necesidad de ejecutar el software. Validación comprueba, ya con el software funcionando, que resuelve la necesidad real del usuario. Verificación responde a "¿lo estoy construyendo bien?", validación a "¿estoy construyendo lo que hace falta?".
¿Qué preguntas sobre casos de prueba son más habituales en la entrevista?
Que expliques cómo decides qué casos escribir para una funcionalidad concreta (un formulario, un carrito de compra) usando partición de equivalencia o valores límite, y que distingas un caso de prueba de un caso de uso. Nombrar la técnica pesa menos que aplicarla sobre el ejemplo que te propongan.
¿Necesito saber programar para pasar una entrevista de QA junior?
No, para la mayoría de puestos junior. Sí ayuda entender para qué sirve la automatización y conocer la diferencia entre herramientas como Playwright, Cypress o Selenium, aunque no las hayas usado todavía en un entorno real.
¿Qué es el método STAR y por qué lo usan en la entrevista?
Es una estructura para responder preguntas de comportamiento: Situación, Tarea, Acción y Resultado. Sirve para evitar respuestas vagas ("suelo trabajar bien en equipo") y obliga a dar un ejemplo real y concreto de cómo actuaste.
¿Cuántas fases suele tener el proceso de selección para QA junior en España?
Lo más habitual son dos: una entrevista con Recursos Humanos centrada en perfil y expectativas, y una entrevista técnica con alguien del equipo de QA o desarrollo. Algunas empresas añaden una prueba práctica corta, como escribir casos de prueba sobre una funcionalidad dada, antes o en lugar de la segunda fase.
¿Quieres entrar al sector?
Aprende QA desde cero, con formación práctica y orientada al mercado español.