¿Qué preguntas debo esperar en una entrevista para ingeniero de calidad?

Los entrevistadores empiezan por el criterio antes que por las herramientas. Deberás explicar cómo decides qué probar en una función que nunca has visto: leer los requisitos y el cambio de código, identificar las rutas de mayor riesgo, elegir qué comprobaciones se ejecutan en los niveles unitario, de integración y de extremo a extremo, y decidir qué permanece manual. La pregunta de seguimiento casi siempre plantea lo contrario: qué no probarías y por qué. Los candidatos capaces de decir que un cambio de configuración de bajo riesgo requiere una prueba de humo en lugar de una regresión completa demuestran el criterio que se busca para el puesto.

• La pirámide de pruebas. Muchas pruebas unitarias rápidas, menos pruebas de integración y pocas pruebas de extremo a extremo. Pregunta de seguimiento: ¿qué sale mal cuando un equipo la invierte?
• Pruebas basadas en riesgos. Priorizar según la probabilidad y el impacto de los fallos, y saber explicar esa priorización a un responsable de producto.
• Técnicas de diseño de pruebas. Partición de equivalencia, valores límite, tablas de decisión y transiciones de estado; deberás aplicar una a un campo de entrada concreto.
• Pruebas no funcionales. Fundamentos de rendimiento, accesibilidad y seguridad, y saber cuándo corresponde evaluar cada aspecto.
• Criterios de salida. Cómo decides que un lanzamiento está listo y qué haces cuando llega la fecha límite antes de que se cumplan los criterios.

Responde con un ejemplo concreto de tu propio trabajo siempre que la pregunta lo permita; las preguntas estratégicas se evalúan por su especificidad.

Automatizas todos los días y esperas que el entrevistador pregunte por las herramientas. En realidad, preguntará por la estructura, así que esta sección aborda las preguntas que revelan si tu automatización está diseñada con rigor o simplemente acumulada.

• Diseño del framework. Capas entre las pruebas y la aplicación (controladores, objetos de página o modelos de pantalla, clientes de API), fixtures compartidos, gestión de datos de prueba, informes y cómo puede un nuevo ingeniero añadir una prueba sin copiar una anterior.
• Pruebas inestables. La pregunta favorita. Diagnostica antes de reintentar: problemas de tiempo y esperas implícitas, estado compartido entre pruebas, dependencia del orden, diferencias entre entornos y comportamiento asíncrono. Explica qué pondrías en cuarentena, qué eliminarías y cómo evitarías que se ignore la suite.
• Pruebas de API y contratos. Probar servicios directamente, validar esquemas y usar contratos guiados por el consumidor que detecten cambios incompatibles antes que las pruebas de extremo a extremo.
• Preguntas sobre herramientas. Selenium, Playwright, Cypress o un framework móvil; clientes REST; una herramienta de carga. A los entrevistadores les importa menos cuál utilizaste que por qué la elegiste y cuáles son sus límites.
• Programación. Deberás escribir una pequeña prueba o utilidad en Python, Java, JavaScript o C#, y explicar cómo probarías una función con varios casos límite.

Relaciona las respuestas: un framework con capas claras permite diagnosticar las pruebas inestables, y las pruebas de contratos permiten mantener pequeña la capa de extremo a extremo.

En los procesos para puestos sénior te plantean una situación. Un ejemplo representativo: a un ingeniero de calidad que se entrevista para un puesto sénior en una empresa de software sanitario le dicen que un lanzamiento saldrá dentro de dos días, que la suite de extremo a extremo lleva una semana en rojo y que los desarrolladores afirman que los fallos se deben al entorno. Una respuesta sólida separa los fallos por causa antes de discutir el lanzamiento: examina los fallos, distingue los problemas del entorno de los defectos reales, comprueba si las pruebas en rojo cubren los cambios de este lanzamiento y ofrece al responsable del lanzamiento una evaluación del riesgo en lugar de un sí o un no. El entrevistador evalúa el triaje y la comunicación.

Otras situaciones recurrentes: diseñar controles de CI para que una solicitud de incorporación ejecute pruebas unitarias y de contratos mientras las suites más lentas se ejecutan de forma programada; gestionar entornos y datos de prueba para que las pruebas no dependan de una única base de datos compartida; decidir cómo probar un cambio en una integración de terceros que no puedes controlar; informar de un defecto que el desarrollador cuestiona; y medir la calidad sin convertir la cobertura en un objetivo. En cada caso, indica la restricción, elige un mecanismo y explica su coste.

Estas respuestas mejoran mucho cuando las expresas en voz alta y respondes preguntas de seguimiento, que es para lo que sirve el modo de entrevista simulada; los demás bancos por puesto están reunidos en preguntas de entrevista por puesto y tema.

En las rondas conversacionales, sí, dentro de unos límites honestos. La aplicación de escritorio nativa de SubcueAI para macOS y Windows captura el audio del sistema y tu micrófono, y muestra sugerencias breves de respuesta en una superposición local. Así, cuando el entrevistador pregunta cómo diagnosticarías una suite inestable, tienes la lista de comprobación en pantalla mientras explicas tu propia experiencia. La extensión del navegador cubre llamadas en pestañas de Chrome y Edge capturando únicamente el audio de la pestaña de la reunión. Ningún bot entra en la llamada ni se inyecta nada en la página de la reunión; la configuración está en la página del tutorial.

Los límites: las tareas para casa, las pruebas de programación supervisadas, las pantallas grabadas y los portátiles administrados por la empresa quedan fuera del alcance, y un ejercicio en vivo en el que escribes una prueba bajo observación es trabajo tuyo. Aaron Cao, fundador de SubcueAI, describe el producto como un recordatorio de lo que ya sabes en lugar de un guion; por eso funciona a partir de tu currículum y de tu propia forma de expresarte. Carga primero ese currículum; el creador de currículums es donde se guarda el perfil.