Prueba de tester QA: preguntas de casos de prueba y escenarios de automatización
Por qué las preguntas estándar de QA fallan en contratación
La mayoría de las preguntas de entrevista QA caen en dos trampas: o son tan genéricas ("¿Cuál es la diferencia entre pruebas y QA?") que cualquiera que apruebe un examen de certificación puede responderlas, o son tan específicas para tu tech stack que prueban conocimiento del framework en lugar de pensamiento. Los candidatos que memorizan vocabulario de pruebas suenan competentes. Los que realmente rompen software y arreglan procesos son invisibles.
Las buenas preguntas QA miden estrategia de prueba, no terminología. Exponen qué hacen realmente los candidatos cuando no tienen un plan de pruebas a seguir.
Pregunta de ejemplo #1: El escenario de informe de defecto
"Estás probando un flujo de checkout de e-commerce. El gateway de pago a veces acepta transacciones duplicadas—mismo ID de orden, misma cantidad, dentro de 5 segundos. Sucede aproximadamente 1 en 50 veces. Camina me a través de cómo investigarías y documentarías esto."
Qué estás midiendo:
- ¿Hacen preguntas aclaratorias (qué método de pago? qué navegador? condiciones de red)?
- ¿Distinguen entre reproducción de defecto, causa raíz y alcance (¿está en su código o del gateway?)?
- ¿Pueden articular un caso de prueba que lo atrape de nuevo?
- ¿Escalarían o intentarían reproducirlo 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 un suite de pruebas que se ejecuta en 2 horas de extremo a extremo. Tu equipo lo 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 haces? Camina me a través de tu razonamiento."
Qué estás midiendo:
- ¿Piensan sobre ROI (costo de automatizar vs. costo de pruebas manuales repetidas)?
- ¿Saben cuándo la automatización es overhead, no eficiencia?
- ¿Pueden estimar honestamente la carga de mantenimiento?
- ¿Consideran fragilidad y 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 es usualmente "depende de qué atrape y qué tan a menudo se rompe."
Pregunta de ejemplo #3: El reto de diseño de prueba
"Estamos construyendo una característica que exporta datos de usuario a CSV. El archivo puede tener 10 a 100,000 filas. ¿Qué probarías? ¿Qué no probarías y por qué?"
Qué estás midiendo:
- ¿Pueden priorizar (formato CSV, edge cases de conteo 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 QA son despiadados sobre alcance. No prueban todo; prueban lo que 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 hubo cambios de esquema, solo limpieza de código. ¿Cuál es tu estrategia de pruebas? ¿Cuál es tu nivel de confianza?"
Qué estás midiendo:
- ¿Quieren ejecutar el full regression suite o pensar críticamente primero?
- ¿Pueden identificar qué podría romperse (consultas N+1, vinculación de datos incorrecta)?
- ¿Entienden la diferencia entre "código cambió" y "riesgo cambió"?
Esto separa analistas de ingenieros. Los ingenieros preguntan "¿qué cambió y qué importa?" Los analistas ejecutan el suite completo 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 de trade-off."
Qué estás midiendo:
- ¿Conocen su base de usuarios (no todos los productos necesitan soporte IE11)?
- ¿Pueden estimar cobertura de navegador vs. costo de pruebas?
- ¿Conocen la diferencia entre navegadores reales y cobertura falsa?
Aquí es donde la opinión importa. "No soportamos IE11, entonces no" es más fuerte que "deberíamos probar todo."
Pregunta de ejemplo #6: La entrevista de codificación en vivo (breve)
"Escribe un caso de prueba en cualquier framework que conozcas mejor. Te daré una función simple: validateEmail(email). Retorna true si es un email válido, false de otro modo. Escribe la prueba—no escribas la función."
Qué estás midiendo:
- ¿Pueden pensar sobre edge cases (string vacío, sin @, múltiples @s, espacios)?
- ¿Escriben pruebas que sean legibles u oscuras?
- ¿Conocen su testing framework (assertions, setup/teardown)?
- ¿Están probando comportamiento o implementación?
Esta es una entrevista de codificación en vivo que toma 10 minutos y expone fluidez de lenguaje, estructura de prueba, y pensamiento.
El patrón que funciona
Las seis preguntas tienen la misma estructura: presentar una situación real (o realista), pedir al candidato que razone a través de ella, y escuchar por juicio, no recuerdo de palabras clave. Las respuestas no son correctas o incorrectas. Son reveladoras.
Las entrevistas que recordarás son aquellas donde un candidato te hace una pregunta aclaratoria que te hace pausar. Esa es la señal. Ese es el contratado.
Cuándo usar evaluaciones escritas en su lugar
No todas las contrataciones QA necesitan una entrevista de codificación en vivo grabada. Una tarea de caso de prueba para llevar a casa puede ser igualmente reveladora: "Aquí hay una especificación de característica. 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 de artefacto con defensa verbal.
Para escalar contratación, plataformas de evaluación que puedan calificar cobertura de casos de prueba, calidad de assertions, y pensamiento de edge cases hacen rondas en vivo más eficientes.
Contra-consideración
Algunos equipos prefieren entrevistas basadas en comportamiento sin terminología de pruebas en absoluto: "Cuéntame sobre un defecto que encontraste que te sorprendió" o "Camina me a través de la última vez que retrocediste en un deadline porque las pruebas no estaban hechas." Esto también funciona, especialmente si estás contratando gente que posee calidad en lugar de gente que son testers.
Las preguntas importan menos que la filosofía: estás midiendo pensamiento, no memoria. Todo lo demás sigue.