Preguntas de entrevista para QA: 50 ejemplos con respuestas

Estas preguntas de entrevista para QA te ayudan a evaluar a quien va a cuidar la calidad de tu software. El profesional de QA evita que los errores lleguen al usuario y protege la experiencia del cliente. Más allá de las preguntas de fit cultural, las preguntas técnicas muestran lo que la persona sabe hacer, más allá de certificados y años de experiencia.

Qué hace un profesional de QA

QA significa Quality Assurance, o aseguramiento de la calidad. Aunque los desarrolladores prueban su código, el QA revisa la calidad del producto completo con una visión más amplia: verifica que se sigan criterios y métodos, detecta desvíos y previene defectos antes de que lleguen al usuario.

Para eso usa herramientas como Selenium, Appium y Cypress para automatizar pruebas, y Jira, Bugzilla o MantisBT para dar seguimiento a bugs. En la entrevista, presta atención a si la persona menciona estas herramientas y si ya usa IA en su trabajo de pruebas.

Antes de la entrevista, valida las habilidades con una prueba técnica

Con Coodesh aplicas pruebas de QA y automatización con calificación automática, y llegas a la entrevista sabiendo en qué profundizar. Prueba gratis las pruebas técnicas.

Preguntas de entrevista para QA Junior

1. ¿Qué es QA?

Es el proceso de asegurar la calidad de un software y prevenir defectos antes de que lleguen al usuario final, con metodologías, pruebas y buenas prácticas que cubren requisitos funcionales y no funcionales.

Qué observar: que conecte QA con prevención y no solo con encontrar errores al final.

2. ¿Por qué es importante en el ciclo de desarrollo?

Identifica y previene errores desde el inicio, lo que reduce costos y retrabajo, y ayuda al equipo a entregar productos más estables.

Qué observar: ejemplos de costo: un bug encontrado en requisitos cuesta mucho menos que uno en producción.

3. ¿Qué es un bug?

Un error, falla o comportamiento inesperado que hace que el sistema no funcione como debería. Puede venir del código, de requisitos mal definidos o de problemas de integración.

Qué observar: que distinga entre bug, requisito mal definido y comportamiento esperado que el usuario no entiende.

4. ¿Cuál es la diferencia entre prueba manual y automatizada?

La manual la ejecuta una persona sin scripts y es más flexible para validaciones exploratorias y visuales. La automatizada usa scripts y herramientas para tareas repetitivas, con más velocidad y cobertura, sobre todo en regresión.

Qué observar: que no vea un tipo como mejor que el otro, sino como complementarios según el contexto.

5. ¿Cuál es la diferencia entre severidad y prioridad?

La severidad mide el impacto técnico del bug. La prioridad define la urgencia de corregirlo según el impacto en el usuario y el negocio. Un bug puede ser muy severo y tener baja prioridad según el contexto.

Qué observar: un ejemplo propio de un bug severo con baja prioridad, como un error en una pantalla que casi nadie usa.

6. ¿Qué es un caso de prueba y qué debe incluir?

Un conjunto de condiciones y pasos para validar una funcionalidad. Incluye ID, descripción, precondiciones, pasos, datos de entrada, resultado esperado y resultado real.

Qué observar: que mencione resultado esperado y datos de entrada. Sin eso, el caso no es repetible.

7. ¿Cuál es la diferencia entre estrategia y plan de pruebas?

La estrategia es de alto nivel: enfoque, tipos de prueba y criterios de aceptación. El plan es específico del proyecto: alcance, calendario, recursos, responsables y casos a ejecutar.

Qué observar: que entienda que la estrategia cambia poco entre proyectos y el plan cambia en cada uno.

8. ¿Qué contiene un plan de pruebas?

Enfoque, alcance, objetivos, recursos, calendario, tipos de prueba, ambientes, criterios de entrada y salida y responsabilidades del equipo.

Qué observar: criterios de entrada y salida claros. Muestran que la persona sabe cuándo empezar y cuándo parar.

9. ¿Qué es el ciclo de vida de un defecto?

Las etapas de un bug desde que se detecta hasta que se cierra: nuevo, en análisis, en corrección, corregido, en prueba y cerrado.

Qué observar: que conozca los estados en la herramienta que usa el equipo, como Jira.

10. ¿Cuándo debe empezar el aseguramiento de la calidad?

Desde el inicio, idealmente en la planeación y el análisis de requisitos, cuando corregir un problema es más barato.

Qué observar: la idea de «shift left»: calidad desde el inicio, no como etapa final.

11. ¿Qué diferencia hay entre aseguramiento de calidad, control de calidad y pruebas?

QA es proactivo y mejora procesos para prevenir defectos. QC es reactivo y detecta defectos en el producto. Las pruebas son parte del QC: ejecutar casos para verificar que el software cumpla los requisitos.

Qué observar: que explique la diferencia con un ejemplo real de su trabajo.

12. ¿Cuáles son los tipos básicos de prueba?

Funcionales (integración, sistema), no funcionales (desempeño, seguridad, usabilidad), regresión y aceptación, como la UAT.

Qué observar: que cite pruebas no funcionales sin que se lo pregunten.

13. ¿Qué diferencia hay entre Assert y Verify?

Assert valida una condición crítica y detiene la prueba si falla. Verify registra el error y deja que la prueba continúe, para ver varios errores en una ejecución.

Qué observar: experiencia real con frameworks de automatización, no solo la definición.

14. ¿Qué métricas usas para evaluar la calidad del producto?

Tasa de defectos, cobertura de pruebas, tiempo de respuesta, tasa de fallas y satisfacción del usuario.

Qué observar: que conecte las métricas con decisiones, no solo que las enumere.

15. ¿Cómo defines un caso de uso?

Una descripción de cómo el usuario interactúa con el sistema para lograr un objetivo: flujo de acciones, condiciones de éxito y excepciones.

Qué observar: capacidad de escribir casos de prueba a partir de un caso de uso.

16. ¿Qué son las pruebas de caja negra y caja blanca?

Caja negra valida funcionalidades sin mirar el código, solo entradas y salidas. Caja blanca examina el código y la estructura interna para revisar caminos y condiciones.

Qué observar: que sepa cuándo usa cada tipo en su día a día.

Preguntas de entrevista para QA Semi Senior

17. ¿Qué es una prueba de regresión y cómo se hace?

Verifica que los cambios en el código no rompan funcionalidades existentes. Se reejecutan casos anteriores, normalmente de forma automatizada.

Qué observar: que mencione automatizar la regresión y elegir qué casos incluir.

18. Explica la automatización de pruebas.

Usar herramientas y scripts para ejecutar pruebas sin intervención manual, con más rapidez, menos error humano y más cobertura en pruebas repetitivas.

Qué observar: que hable de qué no conviene automatizar, además de qué sí.

19. ¿Qué herramientas de automatización has usado?

Respuestas comunes: Selenium para web, JUnit y TestNG para pruebas unitarias en Java, Appium para apps móviles, Jenkins para integración continua y Cucumber para pruebas en lenguaje natural. La elección depende del tipo de aplicación.

Qué observar: profundidad en al menos una herramienta, con ejemplos de proyectos reales.

20. ¿Cómo documentas y reportas defectos?

En una herramienta como Jira o Bugzilla, con descripción, pasos para reproducir, severidad, prioridad, ambiente y capturas o logs. Luego se da seguimiento hasta la corrección.

Qué observar: reportes que un desarrollador pueda reproducir sin hacer preguntas.

21. ¿Qué diferencia hay entre pruebas funcionales y no funcionales?

Las funcionales verifican lo que el sistema hace, como login o cálculos. Las no funcionales evalúan cómo lo hace: desempeño, seguridad, usabilidad y confiabilidad.

Qué observar: ejemplos de pruebas no funcionales que ya ejecutó, como carga o accesibilidad.

22. ¿Cómo priorizas casos de prueba con plazos ajustados?

Por riesgo e impacto: primero lo crítico, como integraciones y seguridad, después la regresión, y automatización para acelerar lo repetitivo.

Qué observar: priorización por riesgo y transparencia con el equipo sobre lo que quedó fuera.

23. ¿Cómo aplicas Six Sigma en QA?

Con el ciclo DMAIC (definir, medir, analizar, mejorar y controlar) para reducir defectos y mejorar el proceso de pruebas de forma continua.

Qué observar: aplicación práctica, aunque sea simple. Six Sigma no es obligatorio en todos los equipos.

24. ¿Cuándo eliges prueba manual o automatizada?

Manual para interacciones complejas y casos únicos. Automatizada para regresión, pruebas repetitivas y alta cobertura. Depende de la frecuencia y complejidad.

Qué observar: criterio de costo y beneficio: frecuencia de ejecución, estabilidad de la funcionalidad y tiempo de mantenimiento.

25. ¿Cómo evalúas un sistema de gestión de calidad?

Con indicadores como tasa de defectos, satisfacción del cliente, cumplimiento de normas y eficiencia operativa, más retroalimentación continua.

Qué observar: que vaya más allá de los defectos e incluya satisfacción del cliente.

26. ¿Qué diferencia hay entre QA y pruebas de software?

QA es el proceso amplio de prevención. Las pruebas son una actividad dentro de QA enfocada en detectar defectos.

Qué observar: que no use los términos como sinónimos.

27. ¿Qué es testware?

Todos los artefactos del proceso de pruebas: casos, scripts, datos, planes y herramientas.

Qué observar: que sepa dónde guarda y cómo versiona estos artefactos.

28. ¿Qué son las pruebas basadas en datos?

Ejecutar la misma prueba con distintos conjuntos de datos para cubrir más escenarios y encontrar fallas que datos limitados no muestran.

Qué observar: un ejemplo con datos límite, inválidos o generados.

29. ¿Cuáles son las etapas del ciclo de un bug?

Identificar y documentar, clasificar, asignar al desarrollador, probar la corrección y cerrar.

Qué observar: que conozca el flujo del equipo y la herramienta usada.

30. ¿Qué son las pruebas ágiles y por qué importan?

Pruebas en ciclos cortos con colaboración constante entre desarrollo y QA. Permiten entregas continuas, retroalimentación rápida y ajustes durante el desarrollo.

Qué observar: experiencia trabajando dentro del sprint, no al final de él.

31. ¿Qué errores comunes cometen los QA?

No actualizar casos de prueba, olvidar las pruebas no funcionales, no priorizar lo crítico, comunicar mal los defectos y hacer poca regresión.

Qué observar: autocrítica: errores que la persona cometió y corrigió.

32. ¿Cuál es el mayor reto de QA hoy?

Mantener cobertura y eficiencia en entornos ágiles con cambios constantes, equilibrando calidad, plazos y automatización.

Qué observar: una visión actual del mercado, que incluya IA y pruebas inestables.

Preguntas de entrevista para QA Senior

33. ¿Cómo armarías un framework de automatización desde cero?

Elegir herramientas, organizar la estructura del proyecto, automatizar primero los flujos críticos e integrar con CI, con plan de mantenimiento y monitoreo.

Qué observar: decisiones de arquitectura justificadas: lenguaje, patrón de diseño y reportes.

34. ¿Qué son las pruebas de carga y de estrés?

Carga evalúa el desempeño con el volumen esperado. Estrés lleva el sistema más allá de su capacidad hasta encontrar el punto de falla.

Qué observar: herramientas concretas, como JMeter o k6, y cómo interpreta los resultados.

35. ¿Cómo garantizas cobertura en aplicaciones muy complejas?

Priorizando escenarios de riesgo, combinando pruebas manuales y automatizadas, caja negra y blanca, regresión y documentación revisada con frecuencia.

Qué observar: priorización por riesgo antes que intentar cubrir todo.

36. ¿Has trabajado con CI/CD en QA?

Una buena respuesta describe pipelines, por ejemplo en Jenkins, que ejecutan pruebas en cada commit y bloquean el despliegue si fallan.

Qué observar: pipelines reales y qué pasa cuando una prueba falla en el pipeline.

37. ¿Cómo usas métricas para mejorar el proceso de QA?

Con cobertura de código, tasa de defectos y tiempo de ejecución para priorizar pruebas críticas y ajustar el proceso.

Qué observar: que use las métricas para cambiar algo, no solo para reportar.

38. ¿Cómo garantizas calidad en la fase de diseño?

Analizando requisitos, involucrando a QA desde el inicio, revisando el diseño, haciendo pruebas de usabilidad y aplicando estándares.

Qué observar: participación en revisión de requisitos y prototipos.

39. ¿Cómo integras la retroalimentación del usuario?

Recolectándola en betas o entrevistas, analizando problemas recurrentes y ajustando casos de prueba y prioridades.

Qué observar: un ejemplo de cambio en las pruebas a partir de lo que dijeron los usuarios.

40. ¿Por qué es importante el FMEA?

El análisis de modo y efecto de falla identifica fallas potenciales y las prioriza por severidad, probabilidad y detectabilidad antes de que causen daño.

Qué observar: capacidad de explicar severidad, probabilidad y detectabilidad.

41. ¿Cómo priorizas en una crisis de calidad?

Primero los defectos críticos y frecuentes que más afectan al usuario, con comunicación constante y ajustes al proceso para evitar que se repitan.

Qué observar: calma, priorización y comunicación con liderazgo.

42. ¿Qué ventajas tiene la prueba manual?

Detecta problemas de usabilidad y experiencia, es flexible ante cambios frecuentes y sirve para pruebas exploratorias o cuando automatizar no conviene.

Qué observar: que defienda la prueba manual sin descartar la automatización.

43. ¿Qué diferencia hay entre número de build y número de versión?

El de build se genera automáticamente en cada compilación. El de versión se asigna para identificar versiones estables.

Qué observar: que conozca el control de versiones del equipo.

44. ¿Qué es una fuga de bugs y un lanzamiento con bugs?

Fuga: fallas que no se detectaron y llegaron a producción. Lanzamiento con bugs: el equipo decide liberar sabiendo que hay fallas conocidas.

Qué observar: responsabilidad sobre las fugas y aprendizaje después de un lanzamiento con bugs conocidos.

45. ¿Cómo haces un análisis de causa raíz?

Reúno datos, uso técnicas como los 5 porqués o el diagrama de Ishikawa, aplico acciones correctivas y preventivas y pruebo que el problema no vuelva.

Qué observar: un ejemplo completo, del problema a la acción preventiva.

46. ¿Qué haces cuando no se cumplen los estándares de calidad?

Analizo las causas, aplico correcciones en las pruebas o el proceso y doy seguimiento en las siguientes versiones.

Qué observar: que proponga cambios de proceso, no solo correcciones puntuales.

47. ¿Cómo desarrollas a QA junior en tu equipo?

Con base teórica, práctica guiada, retroalimentación constante, mentoría y capacitación continua.

Qué observar: experiencia real formando personas y midiendo su avance.

48. ¿Cuándo es apropiado hacer pruebas de regresión?

Después de nuevas funcionalidades, correcciones de bugs, actualización de dependencias, refactorizaciones o cambios en sistemas relacionados.

Qué observar: situaciones específicas en lugar de una respuesta genérica.

49. Describe una estrategia de pruebas que te haya funcionado.

Una buena respuesta combina pruebas unitarias, de integración y de sistema, manuales y automatizadas, con regresión y foco en las áreas críticas.

Qué observar: una estrategia conectada a un producto y a un contexto concretos.

50. ¿Qué herramientas usas en tu día a día?

Por ejemplo, Selenium para interfaz, Jira para defectos, TestRail para casos, Postman para APIs y Jenkins para integración continua.

Qué observar: herramientas que coincidan con el stack del equipo, o capacidad de aprenderlas rápido.

Cómo usar estas preguntas de entrevista para QA en tu proceso de selección

Adapta las preguntas al nivel de la vacante. Para un perfil Junior, enfócate en conceptos; para un Senior, en estrategia, liderazgo y decisiones.
Observa la profundidad. Revisa si las respuestas son coherentes con la experiencia del currículum y pide cómo resolvería problemas del día a día.
Pide ejemplos reales. Proyectos anteriores muestran fortalezas para aprovechar desde el inicio y puntos para trabajar en el plan de desarrollo.

Las respuestas a estas preguntas de entrevista para QA son una referencia. Un buen candidato va más allá y explica el porqué de sus decisiones.

10 preguntas de entrevista para QA sobre comportamiento

Las preguntas técnicas muestran lo que la persona sabe. Las de comportamiento muestran cómo actúa cuando la calidad entra en conflicto con plazos, prioridades o personas. Para cada una, indicamos qué buscar en la respuesta.

Cuéntame de un bug crítico que encontraste poco antes de un lanzamiento. ¿Qué hiciste? Busca claridad para comunicar el riesgo, datos para sustentar la decisión y respeto por quien decide liberar o no.
¿Alguna vez un desarrollador no estuvo de acuerdo con un bug que reportaste? ¿Cómo lo resolviste? Busca colaboración y evidencia, no una competencia por tener la razón.
Describe una vez en que tuviste que probar algo sin documentación. Busca pruebas exploratorias, preguntas a las personas correctas y registro de lo aprendido.
¿Cómo decidiste qué no probar en un sprint con poco tiempo? Busca priorización por riesgo y transparencia sobre lo que quedó fuera.
Cuéntame de un bug que se te escapó y llegó a producción. Busca responsabilidad, análisis de causa y un cambio concreto en el proceso. Desconfía de quien dice que nunca le pasó.
¿Cómo convenciste a tu equipo de invertir en automatización? Busca argumentos de costo y riesgo, no solo de preferencia técnica.
¿Qué hiciste cuando tus pruebas automatizadas empezaron a fallar de forma intermitente? Busca diagnóstico de pruebas inestables, aislamiento de dependencias y disciplina para no ignorar fallas.
¿Cómo trabajas con producto para definir criterios de aceptación? Busca participación desde el inicio y criterios verificables.
¿Cómo usas IA en tu trabajo de pruebas? Busca uso crítico: generar casos o datos de prueba y revisarlos, no aceptar lo que la herramienta entrega sin verificar.
¿Qué mejora de calidad lideraste y cómo mediste el resultado? Busca métricas antes y después, como defectos en producción o tiempo de regresión.

Señales positivas y señales de alerta en las respuestas

Señales positivas:

Habla de riesgo para el usuario y el negocio, no solo de cantidad de bugs.
Da ejemplos concretos con herramientas, contexto y resultado.
Reconoce límites: sabe que no se puede probar todo y explica cómo elige.
Muestra buena relación con desarrollo y producto.
Conoce las pruebas de API y de rendimiento, no solo las de interfaz.

Señales de alerta:

Define su trabajo como «encontrar errores de los desarrolladores».
Responde todo con teoría y ningún ejemplo propio.
No sabe explicar cómo prioriza cuando el tiempo no alcanza.
Dice que automatiza todo, sin criterio sobre qué conviene automatizar.
No menciona documentación ni comunicación de los defectos.

Pruebas prácticas para evaluar a un QA

Una entrevista muestra cómo la persona habla de calidad. Una prueba práctica muestra cómo la hace. Estos tres ejercicios cubren los niveles más comunes:

Ejercicio 1: casos de prueba para un formulario de login (Junior)

Entrega una pantalla de login con requisitos simples (correo, contraseña, bloqueo tras cinco intentos, recuperación de contraseña) y pide que la persona escriba los casos de prueba. Evalúa la cobertura de casos positivos y negativos, límites, mensajes de error, seguridad básica y claridad de los pasos.

Ejercicio 2: reporte de bugs en una aplicación con errores (Semi Senior)

Da acceso a una aplicación de prueba con fallas plantadas y 45 minutos para explorarla. Evalúa cuántos bugs relevantes encuentra, cómo los prioriza y la calidad de cada reporte: pasos para reproducir, resultado esperado, resultado real, severidad y evidencia.

Ejercicio 3: automatización de un flujo crítico (Senior)

Pide automatizar un flujo, como agregar un producto al carrito y pagar, con la herramienta del equipo (Playwright, Cypress o Selenium), más una prueba de API del mismo flujo. Evalúa la estructura del proyecto, la estabilidad de las pruebas, el uso de buenas prácticas como page objects y la explicación de qué dejaría fuera de la automatización y por qué.

QA manual o QA de automatización: qué cambia en la entrevista

QA manual: pon más peso en pruebas exploratorias, diseño de casos, comunicación de defectos y conocimiento del negocio. Las preguntas de entrevista para QA 3, 4, 6, 12 y 15 son las más útiles.
QA de automatización: pon más peso en programación, arquitectura de frameworks, CI/CD y estabilidad de pruebas. Las preguntas 18, 19, 33, 36 y la pregunta de comportamiento sobre pruebas intermitentes ayudan a separar perfiles.
QA de rendimiento o seguridad: agrega preguntas específicas sobre herramientas como JMeter o k6, y pruebas de vulnerabilidades comunes.

Rúbrica para la entrevista de QA

Dimensión	Qué evalúas	Peso sugerido
Fundamentos de calidad	Conceptos, tipos de prueba, ciclo de defectos	25%
Práctica	Resultado de la prueba práctica	35%
Priorización y riesgo	Cómo decide qué probar y cuándo liberar	20%
Comunicación y colaboración	Relación con desarrollo y producto	20%

Ajusta los pesos según el puesto. Para un QA de automatización, la práctica puede pesar más; para un líder de QA, la priorización y la comunicación.

Cómo estructurar una entrevista de QA de 60 minutos

Apertura (5 minutos): presenta el equipo, el producto y cómo será la entrevista. Baja la tensión y mejora la calidad de las respuestas.
Experiencia (10 minutos): pide que la persona cuente su último proyecto y cómo se organizaba la calidad en ese equipo.
Preguntas técnicas (20 minutos): elige entre 8 y 10 preguntas de entrevista para QA de este artículo según el nivel. Profundiza en las respuestas más superficiales.
Preguntas de comportamiento (15 minutos): usa tres o cuatro de la lista y pide ejemplos concretos.
Preguntas del candidato (10 minutos): lo que la persona pregunta también es evidencia. Un buen QA suele preguntar por el proceso de lanzamiento, la cobertura actual y la relación con desarrollo.

Registra la calificación justo después de la entrevista, con la rúbrica, antes de hablar con otras personas del panel. Así evitas que una opinión influya en las demás.

Preguntas frecuentes sobre la entrevista para QA

¿Cuántas preguntas de entrevista para QA usar?

Entre 10 y 15 técnicas y tres o cuatro de comportamiento en una entrevista de una hora. Elige según el nivel y el tipo de QA.

¿Hace falta una prueba práctica?

Sí, sobre todo para automatización. Muchas personas explican bien los conceptos y tienen dificultad para aplicarlos.

¿Qué certificaciones valen la pena?

La ISTQB es la más conocida y muestra base teórica. No sustituye la experiencia práctica ni una buena prueba técnica.

¿Quién debe participar en la entrevista?

Reclutamiento para el filtro inicial, un QA o líder técnico para la parte técnica y, en lo posible, alguien de producto o desarrollo que trabajará con la persona.

Lee también

Conclusión

Con una guía clara, entrevistar a un QA deja de ser un reto para reclutamiento y para el líder técnico. Estas 50 preguntas de entrevista para QA cubren los niveles Junior, Semi Senior y Senior. Para llegar a la entrevista con evidencia, combina la conversación con una prueba técnica.