Preguntas de Ejemplo para Tester QA: Qué Preguntar en Entrevistas Técnicas
Por qué las preguntas estándar de QA fallan en la contratación
La mayoría de preguntas de entrevista para QA caen en dos trampas: son tan genéricas ("¿Cuál es la diferencia entre testing y QA?") que cualquiera que haya pasado un examen de certificación puede responderlas, o son tan específicas de tu stack tecnológico que prueban conocimiento de framework en lugar de pensamiento crítico. Los candidatos que memorizan vocabulario de testing suenan competentes. Los que realmente rompen software y arreglan procesos son invisibles.
Las buenas preguntas de QA miden estrategia de testing, no terminología. Exponen qué hacen realmente los candidatos cuando no tienen un plan de pruebas que seguir. Las evaluaciones estructuradas de QA y automatización de pruebas cierran ambas brechas calificando a los candidatos en trabajo realista de búsqueda de defectos en lugar de vocabulario.
Pregunta de ejemplo #1: El escenario de reporte de bug
"Estás probando un flujo de pago de e-commerce. El gateway de pago a veces acepta transacciones duplicadas—mismo ID de orden, mismo monto, dentro de 5 segundos. Ocurre aproximadamente 1 de cada 50 veces. Recorre cómo investigarías y documentarías esto."
Lo que estás midiendo:
- ¿Hacen preguntas aclaratorias (qué método de pago? qué navegador? condiciones de red)?
- ¿Distinguen entre reproducción de bug, causa raíz y alcance (¿está en su código o en el del gateway?)?
- ¿Pueden articular un caso de prueba que lo capture de nuevo?
- ¿Lo escalarían o intentarían reproducirlo ellos mismos primero?
Esto revela si piensan como ingenieros (causa raíz, alcance, prevención) o solo como reporteros (síntoma, captura de pantalla, ticket).
Pregunta de ejemplo #2: El trade-off de automatización
"Tienes una suite de pruebas que se ejecuta en 2 horas de extremo a extremo. Tu equipo la ejecuta una vez al día. Un compañero propone automatizar el flujo de UI para cargas de imágenes—aproximadamente 40 líneas de Selenium y 15 minutos de mantenimiento por trimestre. ¿Lo harías? Recorre tu razonamiento."
Lo que estás midiendo:
- ¿Piensan en ROI (costo de automatizar vs. costo de re-testing manual)?
- ¿Saben cuándo la automatización es una sobrecarga, no eficiencia?
- ¿Pueden estimar la carga de mantenimiento honestamente?
- ¿Consideran la fragilidad y los falsos positivos?
Los candidatos que dicen "sí, automatiza todo" o "no, las pruebas de UI son frágiles" se pierden el punto. La respuesta correcta suele ser "depende de qué capture y con qué frecuencia se rompa."
Pregunta de ejemplo #3: El desafío de diseño de pruebas
"Estamos construyendo una función que exporta datos de usuario a CSV. El archivo puede tener de 10 a 100,000 filas. ¿Qué probarías? ¿Qué no probarías y por qué?"
Lo que estás midiendo:
- ¿Pueden priorizar (formato CSV, casos límite de recuento de filas, caracteres especiales) vs. ruido (¿importa el color del botón)?
- ¿Saben qué vale la pena automatizar vs. verificar manualmente?
- ¿Pueden articular riesgo (fuga de datos, corrupción de formato) vs. preferencia?
Los buenos ingenieros de QA son despiadados sobre el alcance. No prueban todo; prueban qué podría dañar el negocio.
Pregunta de ejemplo #4: El riesgo de regresión
"Tu equipo acaba de refactorizar las consultas de base de datos en la página de perfil de usuario. No había cambios de esquema, solo limpieza de código. ¿Cuál es tu estrategia de testing? ¿Cuál es tu nivel de confianza?"
Lo que estás midiendo:
- ¿Quieren ejecutar la suite completa de regresión o piensan críticamente primero?
- ¿Pueden identificar qué podría romperse (consultas N+1, binding de datos incorrecto)?
- ¿Entienden la diferencia entre "código cambió" y "riesgo cambió"?
Esto separa a los analistas de los ingenieros. Los ingenieros preguntan "¿qué cambió y qué importa?" Los analistas ejecutan la suite completa sin importar.
Pregunta de ejemplo #5: La pregunta multi-navegador (con un giro)
"Estás probando un nuevo componente de UI en Chrome, Firefox y Safari. Se renderiza correctamente en todas partes. ¿Lo pruebas en IE11? ¿En Chrome móvil? ¿En navegadores basados en Chromium como Edge? Toma la decisión del trade-off."
Lo que estás midiendo:
- ¿Conocen su base de usuarios (no todos los productos necesitan soporte en IE11)?
- ¿Pueden estimar la cobertura de navegadores vs. costo de testing?
- ¿Conocen la diferencia entre navegadores reales y cobertura falsa?
Aquí es donde la opinión importa. "No soportamos IE11, así que no" es más fuerte que "deberíamos probar todo."
Pregunta de ejemplo #6: La entrevista de live coding (breve)
"Escribe un caso de prueba en el framework que mejor conozcas. Te daré una función simple: validateEmail(email). Devuelve true si es un email válido, false en caso contrario. Escribe la prueba—no escribas la función."
Lo que estás midiendo:
- ¿Pueden pensar en casos límite (string vacío, sin @, múltiples @s, espacios)?
- ¿Escriben pruebas que son legibles o crípticas?
- ¿Conocen su framework de testing (assertions, setup/teardown)?
- ¿Están probando comportamiento o implementación?
Esto es una entrevista de live coding que toma 10 minutos y expone fluidez del lenguaje, estructura de pruebas y pensamiento.
El patrón que funciona
Las seis preguntas tienen la misma estructura: presenta una situación real (o realista), pide al candidato que razone sobre ella, y escucha por juicio crítico, no recuperación de palabras clave. Las respuestas no son correctas o incorrectas. Son reveladoras.
Las entrevistas que recordarás son aquellas en las que un candidato te hace una pregunta aclaratoria que te hace pausar. Esa es la señal. Ese es el candidato a contratar.
Cuándo usar evaluaciones escritas en su lugar
No toda contratación de QA necesita una entrevista de live coding grabada. Un proyecto de prueba take-home puede ser igualmente revelador: "Aquí hay una especificación de función. Escribe 10-15 casos de prueba que propondrías a tu equipo. Explica tu prioridad." Luego haz preguntas de seguimiento en la siguiente ronda sobre su razonamiento. Esto combina calidad del artefacto con defensa verbal.
Para escalar la contratación, plataformas de evaluación que pueden calificar cobertura de casos de prueba, calidad de assertions y pensamiento sobre casos límite hacen las rondas en vivo más eficientes.
Consideración contrapuesta
Algunos equipos prefieren entrevistas behavior-first sin terminología de testing en absoluto: "Cuéntame sobre un bug que encontraste que te sorprendió" o "Recorre la última vez que cuestionaste un deadline porque el testing no estaba hecho." Esto también funciona, especialmente si estás contratando gente que se apropia de la calidad en lugar de gente que es tester.
Las preguntas importan menos que la filosofía: estás midiendo pensamiento, no memoria. Todo lo demás sigue.