Las entrevistas de QA Automation prueban conocimiento de frameworks, patrones de automatización, y — sobre todo — si puedes escribir tests que se mantengan verdes por razones distintas a la suerte. Aquí están las preguntas comunes con respuestas modelo. Senior: arquitectura, trade-offs, mentoría y toma de decisiones.
En términos que ya usan: costo por release, tiempo desde el commit hasta la confianza, defectos que llegan a los clientes. Una suite que cuesta dos ingenieros al mes y ahorra diez horas manuales por release se paga en una cadencia semanal y no en una trimestral — la aritmética difiere por equipo y debería mostrarse, no afirmarse. La parte honesta de la respuesta es nombrar qué no se va a automatizar y por qué.
Mide antes de tocar nada: qué tests fallan más, cuáles toman más tiempo, cuáles nunca atraparon un defecto real. Usualmente un pequeño número explica la mayor parte del dolor. Pon en cuarentena los flaky para que el build se ponga verde y el equipo empiece a confiar de nuevo, luego arréglalos o bórralos. Borrar es una opción real — un test en el que nadie confía tiene valor negativo porque cuesta atención y no da nada.
Ayuda cuando gente que no es ingeniera genuinamente lee y escribe los escenarios, lo cual es raro y requiere que alguien sea dueño del lenguaje. Empeora las cosas cuando el equipo escribe Gherkin para sí mismo: obtienes una capa en inglés sobre código que nadie afuera lee, más una indirección de step-definitions que convierte un cambio de dos líneas en una cacería. Si el product owner nunca abre los feature files, déjalos.
Pesa las cosas que son caras de cambiar: el lenguaje que el equipo ya escribe, cómo maneja el tool la espera, si puede correr en CI sin display, y qué tan sano está el proyecto — cadencia de releases, edad de issues abiertos. Los benchmarks de velocidad importan menos porque el runtime de la suite está dominado por tu aplicación, no por el driver. Pregunta qué pasa cuando la herramienta se abandona.
Un fallo que dice qué se rompió en vez de que una aserción devolvió false: el paso, el screenshot, el log de red, el diff entre esperado y real. Agrupar por causa sospechada en vez de por archivo importa más que el styling. La medida real es si un ingeniero puede decidir en treinta segundos si el fallo es suyo — cualquier cosa más larga y el reporte se salta.
Defectos escapados primero — bugs que llegaron a producción en un área cubierta por tests, ya que eso es lo que la suite existe para prevenir. Luego la tasa de flakiness y el tiempo desde el commit hasta una señal confiable. El porcentaje de cobertura es la métrica de la que desconfiar: es fácil subirla sin testear nada significativo, y un equipo al que se le pide subirla lo hará.
En una entrevista real hablas bajo presión. Cam hace estas mismas preguntas, evalúa cada respuesta y muestra exactamente qué mejorar.
Practicar entrevista de Senior QA Automation →