Llegar a una entrevista técnica de QA con el CV impecable y quedarte en blanco ante la primera pregunta es más común de lo que parece. La buena noticia es que las preguntas se repiten bastante, y prepararlas con tiempo cambia por completo cómo te sientes y cómo respondes. Repasamos las más frecuentes por área y cómo plantear tus respuestas, para que expliques lo que sabes con claridad y con ejemplos.
La regla de oro: un ejemplo siempre
Una respuesta correcta pero abstracta rinde menos que una con un ejemplo de tu experiencia. Siempre que puedas, sigue este esquema: define el concepto en una frase, explica cuándo se usa y da un caso real o realista. Quien entrevista no busca recitar un manual, busca entender cómo piensas.
Preguntas de fundamentos en una entrevista técnica de QA
Una clásica es la diferencia entre error, defecto y falla: el error es la equivocación humana, el defecto es el fallo en el producto causado por ese error y la falla es lo que ocurre cuando el defecto se manifiesta al ejecutar el software. Otra es la de verificación y validación: verificar es comprobar que construimos el producto correctamente según lo especificado, validar es comprobar que construimos el producto correcto para la necesidad del usuario. También suele aparecer severidad frente a prioridad (la severidad mide el impacto técnico del bug, la prioridad la urgencia de resolverlo para el negocio) y la pregunta de qué tipos de prueba conoces, con funcionales y no funcionales, regresión, humo, exploratorias, de integración y de aceptación.
Diseño de pruebas
Te pueden pedir cómo diseñarías casos para un formulario: lo esperado es hablar de partición de equivalencia y valores límite, casos positivos y negativos, validaciones de campos obligatorios y formatos. Si preguntan cómo priorizarías con poco tiempo, la respuesta es por riesgo, combinando impacto y probabilidad de fallo. Y casi siempre aparece cómo escribes un buen reporte de bug: título claro, pasos para reproducir, resultado esperado y real, evidencia, entorno y severidad.
API y datos
Los métodos HTTP más comunes (GET, POST, PUT, PATCH y DELETE, con su uso típico), el significado de los códigos de estado (200 éxito, 400 solicitud inválida, 401 no autenticado, 404 no encontrado, 500 error del servidor) y cómo verificarías datos en la base: consultas SQL básicas con SELECT, filtros y JOIN para comprobar que lo que muestra la aplicación coincide con lo almacenado.
Automatización
Qué automatizarías primero (pruebas de humo y regresión de flujos críticos, estables y repetitivos), qué es el Page Object Model (un patrón que separa los elementos y acciones de cada página del código de las pruebas para reutilizar y mantener), cómo reduces las pruebas inestables (esperas inteligentes, datos controlados, entornos estables, localizadores robustos) y cómo integrarías las pruebas en CI/CD, ejecutándolas con cada cambio y publicando los reportes.
Situaciones y comportamiento
Aquí cuenta menos el dato y más el criterio. Si un desarrollador dice que lo que reportaste no es un bug, lo adecuado es revisar los requisitos, reproducir con evidencia, hablar con calma y, si hace falta, involucrar a producto. Si te preguntan cómo manejas la presión de una entrega, hablas de priorizar por riesgo y de comunicar con transparencia lo que queda sin cubrir. Y prepárate para contar un bug del que te sientas orgulloso, con contexto, cómo lo detectaste y qué impacto evitaste.
Sobre la preparación
Unas semanas de práctica regular rinden más que una noche de repaso, y responder en voz alta, solo o con alguien, mejora la fluidez. Si no sabes una respuesta, dilo con honestidad y explica cómo lo investigarías: se valora tanto el razonamiento como el dato. Quien explica con claridad destaca incluso sin saberlo todo.
Si quieres información sobre cómo preparar tu perfil y tus entrevistas, escríbenos desde el formulario de contacto y te orientamos.
¡Hasta la próxima!