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. Middle: comprensión más profunda, optimización y situaciones reales de trabajo.
1
¿Qué pertenece a cada capa del test pyramid, y qué pasa cuando la forma se invierte?
Respuesta
Los unit tests cubren lógica y corren en milisegundos, los integration tests cubren las costuras entre componentes, y los end-to-end tests cubren un puñado de caminos que nunca deben romperse. Cuando la forma se invierte en un cono de helado — mayormente tests de UI — la suite se vuelve lenta, flaky y cara de mantener, y el equipo empieza a ignorar builds rojos. La pirámide es una afirmación sobre velocidad de feedback, no sobre porcentaje de cobertura.
2
¿Cómo habla la librería cliente con el navegador?
Respuesta
Selenium envía requests HTTP a un proceso driver, que los traduce al propio protocolo de automatización del navegador — un round trip por comando, por eso los tests chatty son lentos. Playwright mantiene una sola conexión WebSocket y habla el protocolo DevTools directamente, por eso puede esperar automáticamente e interceptar tráfico de red. Esa diferencia arquitectónica explica la mayoría de las prácticas.
3
¿Cómo corres tests en paralelo sin que interfieran?
Respuesta
Cada test necesita sus propios datos y su propio contexto de navegador. Los fixtures compartidos creados una vez para la suite son el culpable usual — dos tests mutan al mismo usuario y fallan solo cuando el timing coincide. El arreglo es crear datos por test con una clave única y limpiarlos después, y usar un contexto fresco por worker para que las cookies y el storage no se filtren entre ellos.
4
Un test pasa localmente y falla en CI. Nombra las causas probables en orden.
Respuesta
Timing primero — CI es más lento, así que una race que nunca viste localmente se vuelve visible. Luego entorno: versión de navegador distinta, una fuente faltante cambiando el layout, una zona horaria distinta. Luego datos: un registro sobrante localmente que CI no tiene, o al revés. Luego paralelismo, si CI corre lo que tú corriste en serie. Revisar en ese orden lo encuentra mucho más rápido que leer el diff.
5
¿Qué mockeas en un test automatizado, y qué no?
Respuesta
Mockea servicios de terceros que no controlas, especialmente los pagos, y cualquier cosa no determinista — tiempo, aleatoriedad. No mockees tu propio backend en un test end-to-end, porque entonces estás testeando el frontend contra una ficción. La interceptación de red es el punto medio útil: deja correr el sistema real, y stubea solo la llamada que necesitas que falle a demanda.
6
¿Cómo encuentra un HashMap un valor, y por qué importa hashCode?
Respuesta
Hashea la clave para elegir un bucket, luego compara con equals dentro de ese bucket. Si hashCode es pobre o constante, todo cae en un bucket y la búsqueda degrada de tiempo constante a un escaneo lineal de una lista. Por eso sobreescribir equals sin sobreescribir hashCode es un bug: dos objetos que son iguales van a hashear distinto y desaparecer del map en el que acabas de ponerlos.
7
¿Qué es un contract test y qué atrapa que los end-to-end no?
Respuesta
Verifica que un productor y un consumidor acuerden en la forma de un mensaje, independientemente de correr ambos a la vez. Atrapa el cambio que nadie anunció — un campo renombrado, un tipo ampliado, un opcional hecho requerido — en el momento en que se introduce en vez de en la corrida nocturna. Su valor crece con la cantidad de servicios, que también es por qué un monolito único raramente lo necesita.