Mock interview de QA engineer — práctica con IA

Las entrevistas de QA se dividen en dos tracks: roles manuales/de estrategia de testing y roles de SDET/automatización, y buscan señales muy distintas. El QA manual quiere a alguien capaz de romper una feature en quince minutos y escribir un reporte de bug claro; el SDET quiere a alguien que programa como un backend engineer pero piensa como un tester. La mayoría de los candidatos pierde por apuntar al objetivo equivocado. Esta guía muestra cómo ensayar el loop de entrevista de QA engineer con mocks de IA, calibrado a su track.

Rondas típicas de una entrevista de QA engineer

El loop de QA consta de 4 rondas en la mayoría de las empresas. Una charla con el recruiter, una entrevista de estrategia de testing (te dan una feature y te preguntan cómo la testearías), una ronda práctica (escribir código de automatización o recorrer una investigación de bug) y una behavioral. Los roles de SDET añaden una entrevista de coding que parece una entrevista de backend junior o de nivel medio — DSA ligero, más patrones específicos de testing (page object model, fixtures, parametrización). Los loops de QA senior incluyen una ronda de estrategia de calidad: ¿cómo subirías el listón en una organización sin disciplina de testing?

La ronda de estrategia de testing y la de estrategia de calidad son donde más ayudan los mocks de IA. Ambas son abiertas, ambas recompensan el pensamiento estructurado, ambas penalizan las respuestas genéricas. La ronda de coding de automatización también se beneficia del mock — verbalizar por qué tu test falla con selectores inestables cala más fuerte que solo escribir el código. El testing exploratorio puramente manual es más difícil de mockear; para eso, combine el mock de IA con práctica deliberada en apps reales.

Principales temas técnicos

Estrategia de testing y pirámides

La pirámide de testing es más antigua que la mitad de los candidatos de QA con los que he hablado, pero los entrevistadores aún esperan que la comentes. Esté listo: cuándo se rompe la pirámide (microservicios, mobile, features dirigidas por ML), qué la sustituye (test diamond, honeycomb), la diferencia entre testear para confianza vs para cobertura, y qué significa en la práctica «este código tiene un 90 % de cobertura pero ningún test». Las respuestas fuertes separan la confianza (¿el test prueba que la cosa funciona?) de la cobertura (¿el test ejecutó la línea?).

Frameworks de automatización

Playwright ha superado a Selenium en proyectos nuevos, pero Selenium-WebDriver aún mueve enormes suites de empresa. Cypress ocupa el nicho amigable para front-end developers. Esté listo para comentar: las diferencias reales (el auto-wait de Playwright, los límites de iframe de Cypress, el modelo de grid de Selenium), cuándo elegirías cuál y cómo migrar una suite sin romper al equipo de desarrollo. Para testing de API: REST Assured, Postman/Newman, pytest + requests, Karate. Para mobile: Appium, XCUITest, Espresso, Maestro.

Diseño de tests y datos

Análisis de valores límite, partición de equivalencia, tablas de decisión, pairwise testing — los entrevistadores esperan fluidez en el vocabulario aunque no dibujes la tabla en una pizarra. Esté listo para hablar de estrategia de datos de test: sintéticos vs clonados de producción, manejo de PII, gestión de fixtures a escala, qué significa de verdad «test flaky» (datos, timing, entorno, race conditions) y cómo depurarías un test que falla 1 de cada 50 ejecuciones.

Testing de API

Los tests de API son donde la mayoría de las suites de automatización deberían pesar, y donde muchas fallan. Esté listo para: contract testing (Pact, Spring Cloud Contract), validación de esquemas, tests de idempotencia, comportamiento de retry, rutas de autenticación, rate limiting, y la diferencia entre testear una API y testear un sistema a través de una API. Una pregunta favorita: «la API devuelve 200 para una petición inválida — ¿es eso un bug?». Las respuestas fuertes separan el contrato de la API de la lógica de negocio.

Integración con CI/CD

Los tests que no corren en cada commit no cuentan. Esté listo: ejecución en paralelo, sharding de tests, qué hacer cuando la suite tarda 90 minutos, cuarentena de tests flaky, selección de tests (correr solo los tests relevantes para un cambio) y reporting (XML de junit, Allure, ReportPortal). Los loops de QA senior esperan que diseñes todo el pipeline desde el green-commit hasta el deploy en producción con quality gates en cada etapa.

Preguntas de escenario habituales

• «Te dan una pantalla de login. ¿Cómo la testeas?» (Cubre happy path, estados de error, seguridad, accesibilidad, rendimiento, internacionalización, casos límite — de forma estructurada.)
• «El equipo tiene un 3 % de tests flaky y el build está en rojo la mitad del tiempo. ¿Qué haces?» (Categorizar, poner en cuarentena, arreglar causas raíz, añadir monitorización.)
• «Diseña una estrategia de tests de regresión para un flujo de checkout que se integra con 4 servicios de terceros.» (Service virtualization, contract testing, sandbox de pago real, monitorización.)
• «Te piden añadir "tests generados por IA" a la suite. ¿Qué dices?» (Tradeoffs, dónde ayuda lo generado por IA, dónde produce ruido.)
• «El equipo quiere saltarse el QA y entregar con feature flags. ¿Frenas o aceptas?» (Shift-left, monitorización, rollback, blast radius, confianza del cliente.)

Áreas de enfoque behavioral — qué buscan los hiring managers

Los hiring managers de QA filtran por tres rasgos. Primero, defensa sin abrasión — ¿puedes frenar un release sin que el equipo de desarrollo te odie? Las historias fuertes muestran cómo argumentaste con datos, asumiste la recomendación y dejaste decidir al equipo. Segundo, mentalidad exploratoria — ¿encuentras bugs que nadie más piensa en buscar? Cuente con prompts sobre un bug memorable; responda con el rastro de curiosidad que llevó hasta él, no solo con el bug en sí. Tercero, comodidad con la ambigüedad — al QA a menudo le llega una spec a medio escribir y le piden que la testee. Los hiring managers quieren a alguien que clarifica, documenta y avanza, no a alguien que espera requisitos perfectos.

Cómo usar la práctica de mock con IA para este rol

Ponga el tipo de entrevista en «Tech Screening» y elija su track — manual/estrategia o SDET/automatización. La IA calibra las preguntas en consecuencia. Pegue la oferta si la tiene; las menciones de frameworks en el anuncio (Playwright vs Selenium vs Cypress) moldean mucho el pool de preguntas.

Para practicar estrategia de testing, haga sesiones basadas en escenarios: «te dan la feature X, ¿cómo la testeas?». Cinco seguidas de estas en dominios distintos (e-commerce, fintech, mobile, B2B SaaS) construyen el músculo del pattern-matching. Para practicar coding de SDET, combine el mock con un editor real — el mock se encarga del walkthrough verbal de por qué tu test está estructurado como está.

Un drill infrautilizado: haga que la IA interprete a un desarrollador testarudo que no quiere arreglar tu reporte de bug. Practique argumentar con calma y con evidencia. Esa conversación es la mitad del día a día del QA y casi nunca se ensaya.

Preguntas frecuentes