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.
Cada pregunta viene con una respuesta modelo con la que puedes comparar la tuya.
Page Object Model envuelve cada página o componente en una clase que expone locators y acciones de alto nivel, así los tests describen intención en vez de clicks. El problema que resuelve es mantenimiento: cuando la UI cambia, actualizas un page object en vez de cincuenta tests. También elimina duplicación y hace los tests legibles para gente que no los escribió.
Un wait implícito es una configuración global que hace que cada búsqueda de elemento reintente hasta N segundos. Un wait explícito apunta a una condición específica — elemento clickeable, texto presente — y solo espera por eso. Un fluent wait es un wait explícito con un intervalo de polling configurable y excepciones ignorables. Mezclar waits implícitos y explícitos causa timeouts acumulados impredecibles, así que la mayoría de los equipos deshabilita los waits implícitos por completo y usa explícitos.
El orden preferido es un atributo de test dedicado como data-testid, luego id, luego un selector CSS estable. XPath tiene mala reputación porque el XPath absoluto se rompe con cualquier cambio del DOM, y los XPath relativos largos son difíciles de leer. XPath en sí está bien y a veces es necesario — por ejemplo seleccionar por texto visible o navegar a un padre — el problema es el XPath frágil, no el lenguaje.
Un test flaky pasa y falla sin ningún cambio de código. Las causas usuales son suposiciones de timing (sleeps duros en vez de esperar una condición), datos de prueba mutables compartidos, dependencia del orden de tests, animaciones, y entornos o servicios de terceros inestables. Arreglos: esperar condiciones explícitas, generar datos aislados por test, hacer los tests independientes e idempotentes, stubear servicios externos, y poner en cuarentena los tests flaky en vez de reintentar hasta que pasen.
El paralelismo se configura a nivel del runner y usualmente se combina con un Selenium Grid o contenedores. Los problemas son estado compartido: tests escribiendo a la misma cuenta de usuario o filas de base de datos, colisiones de puertos y archivos, y suposiciones dependientes del orden. El arreglo es que cada test crea sus propios datos con identificadores únicos, evita setup global que muta recursos compartidos, y nunca asume que corre solo.
Playwright habla con los navegadores sobre el protocolo DevTools, hace auto-wait para que los elementos sean accionables, y viene con tracing, interceptación de red, y aislamiento paralelo integrados — así que necesita mucha menos plomería de espera. Selenium es un estándar W3C con el soporte más amplio de navegadores, lenguajes, y grid, y está arraigado en infraestructura empresarial existente. Elige Playwright para un proyecto nuevo enfocado en navegadores modernos; elige Selenium cuando necesitas amplio soporte legacy o debes encajar en un ecosistema Selenium existente.
Verificas códigos de status, schema de la respuesta, valores del body, headers, y manejo de errores para input inválido, más límites de autenticación y autorización. Las herramientas típicamente son Postman o Insomnia para exploración y RestAssured, Playwright APIRequest, requests, o supertest para suites automatizadas. Los tests de API son más baratos y mucho más estables que los tests de UI, así que la mayoría de la cobertura debería vivir ahí.
La pirámide dice que deberías tener muchos unit tests rápidos, menos integration tests, y muy pocos end-to-end tests, porque el costo y la flakiness suben mientras subes. Una división comúnmente citada es aproximadamente 70/20/10, pero el número importa menos que el principio: empuja cada verificación al nivel más bajo que pueda atrapar el bug. Los tests E2E deberían cubrir solo journeys críticos de usuario, no lógica de negocio.
Los tests corren en cada pull request, usualmente divididos en una suite de smoke rápida en cada commit y la regression completa en merge o nocturna. El pipeline provisiona un entorno limpio, corre suites en paralelo, publica reportes y artifacts como screenshots y traces, y falla el build en regresiones. La regla que hace que funcione es que un pipeline rojo bloquea el merge — si no, la suite se degrada.
Data-driven testing separa la lógica del test de los datos del test, así un test corre contra muchos sets de input desde un CSV, JSON, o un provider parametrizado. Multiplica la cobertura sin multiplicar el código y hace que agregar un caso nuevo sea un cambio de datos en vez de un cambio de código. La trampa es generar fallos ilegibles — siempre incluye los datos de input en el nombre del test para que un fallo te diga qué caso se rompió.
Automatiza verificaciones estables, repetitivas, de alto valor: suites de regression, smoke tests, contratos de API, y escenarios pesados en datos. No automatices UI que cambia rápido, verificaciones de una sola vez, trabajo exploratorio, juicio visual y de usabilidad, o cualquier cosa donde escribir y mantener el test cueste más que correrlo manualmente. La pregunta decisiva es cuántas veces correrá la verificación antes de que cambie.
Cada test debería crear los datos que necesita y limpiar después de sí mismo, idealmente a través de llamadas API o seeding de base de datos en vez de la UI, porque eso es más rápido y menos frágil. Los datos de fixture compartidos llevan a dependencia de orden y fallos misteriosos. Para entornos, contenedores o instancias efímeras por corrida de pipeline dan aislamiento; cuando un entorno compartido es inevitable, namespacea todos los datos con un identificador de corrida único.
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 QA Automation →