Las preguntas de comportamiento en las entrevistas de QA evalúan algo específico: si puedes rebatir a un desarrollador que cierra un bug válido, decirle a un PM que su deadline implica cobertura sin testear, y hacerte cargo de un error cuando algo llega a producción. Los entrevistadores esperan el formato STAR (Situación, Tarea, Acción, Resultado), y el fallo más común es detenerse en la Acción y saltarse el Resultado, que es la única parte que hace creíble la historia. Esta guía cubre las preguntas que aparecen con más frecuencia, con respuestas de ejemplo completas y los errores que hacen que los candidatos suenen pasivos o evasivos.

Por qué las preguntas de comportamiento importan en QA

QA es un rol colaborativo. Trabajas con desarrolladores que pueden no estar de acuerdo con tus reportes de bugs, PMs que quieren saltarse el testing para cumplir un deadline, y stakeholders que quieren garantías que no puedes dar. Los entrevistadores usan las preguntas de comportamiento para descubrir: ¿puedes manejar estas situaciones de forma profesional?

Las cosas que evalúan sin decirlo:

  • Comunicación: ¿Puedes explicar problemas técnicos a personas no técnicas?
  • Colaboración: ¿Trabajas con los desarrolladores o en su contra?
  • Criterio: ¿Puedes tomar buenas decisiones bajo presión?
  • Responsabilidad: ¿Te haces cargo o pasas la culpa?
  • Mentalidad de crecimiento: ¿Aprendes de los fracasos y los errores?

El formato STAR

Cada respuesta de comportamiento debe seguir esta estructura:

S: Situación

¿Cuál era el contexto? (1-2 oraciones)

T: Tarea

¿Cuál era tu responsabilidad específica? (1 oración)

A: Acción

¿Qué hiciste tú? (Esta es la parte principal: sé específico)

R: Resultado

¿Qué pasó? Cuantifica si es posible. (1-2 oraciones)

No te saltes la R. El resultado es lo que hace creíble la historia. "El bug fue corregido" está bien. "El bug fue corregido antes de que publicáramos, y después supimos que habría afectado al 30% de los usuarios" es mucho mejor.

Las preguntas clave y respuestas sólidas

"Contame sobre una vez que encontraste un bug crítico justo antes de un release."

Qué evalúan

Cómo manejas situaciones de alta presión, tus habilidades de comunicación, tu criterio sobre el riesgo.

Respuesta sólida (STAR)

Situación: "Estábamos en el testing final de una función de pago importante, programada para publicarse a la mañana siguiente. Tarde por la noche estaba ejecutando tests de regresión." Tarea: "Yo era responsable de dar el visto bueno al release desde la perspectiva de QA." Acción: "Encontré que el código de descuento se aplicaba de forma incorrecta: se restaba del total equivocado, así que los usuarios que aplicaban un descuento podían terminar pagando más en ciertos casos extremos. Documenté el bug de inmediato con los pasos para reproducirlo, creé un ticket de alta prioridad y le escribí directamente al líder de ingeniería y al product manager, no solo en el ticket. Les di el escenario exacto: 'este es el input, esto es lo que pasa, este es el impacto financiero'." Resultado: "Decidimos retrasar 24 horas, corregir el cálculo y volver a testear. El bug se corrigió y verificó al día siguiente. El PM me dijo después que haberlo detectado antes del release nos salvó de un problema importante de atención al cliente y potenciales reembolsos."

"Contame sobre una vez que no estuviste de acuerdo con un desarrollador sobre un bug."

Qué evalúan

Tu capacidad para defender la calidad sin ser confrontacional, tu comunicación técnica.

Respuesta sólida

Situación: "Reporté un bug donde el selector de fechas permitía elegir fechas en el pasado en una función de reservas futuras. El desarrollador lo cerró como 'no es un bug': dijo que la especificación no bloqueaba explícitamente las fechas pasadas." Tarea: "Necesitaba decidir si escalar el tema o dejarlo pasar." Acción: "En lugar de simplemente reabrir el ticket, redacté mi razonamiento: la función es un sistema de reservas, permitir fechas pasadas genera reservas inválidas que fallan en la validación del servidor, y los usuarios que seleccionan una fecha pasada reciben un error confuso. Incluí una captura de pantalla de lo que verían. Luego le pedí al desarrollador que revisara juntos los criterios de aceptación, no para 'ganar' sino para alinearnos. También lo planteé en el standup diario como una pregunta, no como un conflicto: '¿Podemos aclarar el comportamiento esperado para las fechas pasadas?' El PM confirmó que debería bloquearlas." Resultado: "La corrección se agregó al siguiente sprint. El desarrollador y yo tuvimos una buena conversación sobre cómo leer entre líneas en los criterios de aceptación: a veces 'reserva' implica solo futuro, aunque no esté escrito explícitamente."

"Contame sobre una vez que tuviste que testear algo sin documentación o con requisitos poco claros."

Qué evalúan

Tu capacidad para resolver problemas, cómo manejas la ambigüedad, si haces las preguntas correctas o simplemente testeas a ciegas.

Respuesta sólida

Situación: "Una función fue desarrollada por un contratista y entregada sin casos de prueba ni especificaciones claras. Me pidieron que la testeara antes de integrarla al producto." Tarea: "Testear y evaluar la calidad de una función sin documentar." Acción: "Primero hablé con el desarrollador: incluso una llamada de 30 minutos me dio la intención: quién usa esto, cómo se ve el éxito, cuáles son los casos extremos que les preocupaban. Luego usé testing exploratorio, tomando notas mientras descubría el comportamiento. Lo traté como una ingeniería inversa de la especificación: documenté lo que la función realmente hacía y lo comparé con lo que tenía sentido para el usuario. Encontré varios puntos donde el comportamiento parecía incorrecto, no por contradecir una especificación escrita, sino por lo que un usuario razonable esperaría. Los escribí como preguntas primero, no como bugs, y los revisé con el PM para obtener confirmación antes de registrarlos." Resultado: "Identificamos 4 defectos reales, 2 de los cuales el equipo acordó que eran problemas incluso sin una especificación. También creé un documento de especificación informal a partir de mis notas de testing, que se convirtió en la referencia para los tests de regresión futuros."

"Contame sobre una vez que dejaste pasar un bug que llegó a producción."

Qué evalúan

Tu responsabilidad, tu capacidad para aprender de los errores, tu pensamiento post-mortem. Es una pregunta trampa para candidatos que afirman que nunca se escapa nada.

Respuesta sólida

Situación: "Un bug pasó por alto donde los emails de notificación a los usuarios mostraban el estado incorrecto del pedido. Solo ocurría para una combinación específica de tipo de pedido y método de pago." Tarea: "Hacerme cargo de mi parte en lo que pasó y prevenir que se repitiera." Acción: "Cuando se descubrió después del release, hice un análisis de causa raíz de mi testing. Había testeado el flujo de notificaciones, pero solo con el tipo de pedido por defecto. La combinación que desencadenaba el bug no estaba en mis casos de prueba: no había pensado en la matriz de tipo de pedido × método de pago. Después de que se desplegó la corrección, agregué un suite de tests de tabla de decisiones específico para los escenarios de notificación, cubriendo todas las combinaciones relevantes. También agregué esta categoría de testing a nuestra definición de terminado para cualquier función que enviara notificaciones." Resultado: "En los siguientes tres sprints, el suite de tests ampliado detectó 2 problemas en la lógica de notificaciones antes de que se publicaran. La retrospectiva fue incómoda pero mejoró genuinamente nuestro proceso."

"Contame sobre una vez que tuviste que priorizar cuando tenías más testing que tiempo."

Qué evalúan

Tu pensamiento basado en riesgos, tu comunicación sobre el alcance.

Respuesta sólida

Situación: "Tres funciones salieron de desarrollo al mismo tiempo en el penúltimo día del sprint. Realísticamente solo podía testear dos de ellas a fondo." Tarea: "Decidir qué testear y comunicar la situación." Acción: "Evalué el riesgo de cada función: la primera era un nuevo flujo de pago (alto riesgo: dinero en juego, muchos usuarios), la segunda era un cambio de UI en la página de perfil del usuario (riesgo medio, cosmético), la tercera era una función de reportes solo para administradores (menor riesgo, audiencia pequeña). Dediqué el tiempo completo de testing al pago, un testing exhaustivo pero más rápido al perfil, y un smoke testing básico a los reportes. Le avisé al PM: 'Hice smoke testing en los reportes de admin pero no cubrí todos los escenarios. Si publicamos, deberíamos monitorear por problemas y planificar un testing exhaustivo en el próximo sprint'." Resultado: "Publicamos. Había un bug de visualización menor en los reportes de admin que los usuarios detectaron en un día, pero como era solo para admin y cosmético, el impacto fue bajo. Sin problemas críticos. El PM apreció la transparencia: prefería saber qué no estaba testeado antes de enterarse después de un incidente en producción."

"¿Cómo manejas la presión de los stakeholders para reducir el tiempo de testing?"

Situación: "El lanzamiento de un producto se adelantó una semana sin reducción de alcance." Tarea: "Mantener la calidad trabajando con menos tiempo." Acción: "Tuve una conversación directa con el PM: 'Tenemos menos tiempo pero el mismo alcance. Esto es lo que puedo cubrir a fondo y esto es lo que tendré que saltarme o hacer solo smoke testing. ¿Qué te importa más?' Creé una matriz de riesgo simple: funciones por impacto en el negocio y probabilidad de un bug. Esa conversación nos movió de 'testear menos' a 'priorizar qué testeamos'. También propuse automatizar el suite de regresión para los caminos felices para poder ejecutarlo en 10 minutos en lugar de 90 minutos de forma manual." Resultado: "Encontramos el balance correcto. Tres funciones tuvieron testing completo, dos tuvieron solo el camino feliz. No se escapó ningún bug crítico. La conversación sobre automatización llevó a un sprint dedicado a la automatización tres meses después."

Otras preguntas para preparar

  • "Contame sobre una vez que tuviste que aprender una nueva herramienta de testing rápidamente."
  • "Describí una situación en la que mejoraste un proceso de testing."
  • "Contame sobre una vez que trabajaste con un desarrollador o colega difícil."
  • "¿Cómo manejaste recibir críticas sobre tu trabajo?"
  • "Contame sobre una vez que fuiste más allá de tu descripción de trabajo para mejorar la calidad."

Para cada una de estas, piensa en una historia específica antes de tu entrevista. Las respuestas vagas ("generalmente trato de comunicarme bien...") son mucho más débiles que las específicas ("en el sprint 4 de mi último proyecto...").

Errores comunes

La no-respuesta

"La verdad es que no me ha pasado eso." Casi nunca es cierto, y suena a evasión.

La respuesta culpabilizadora

Describir el conflicto desde una posición de "yo tenía razón y ellos estaban equivocados." Aunque hayas tenido razón, haz que la historia trate sobre encontrar un terreno común.

Saltarse el resultado

Terminar con "y después presenté el reporte del bug." ¿Qué pasó después? ¿Se corrigió? ¿Qué aprendiste?

La respuesta demasiado larga

El formato STAR debería tomar 2 a 3 minutos como máximo. Practica para reducirla.

→ See also: Top 50 Preguntas de Entrevista para QA Engineer en 2026 (Con Respuestas) | Preguntas de Entrevista Agile para QA: Qué Esperar y Cómo Responder | Cómo Prepararse para una Entrevista Técnica QA: Guía Paso a Paso