Las entrevistas técnicas para ingenieros QA se han vuelto cada vez más rigurosas. En 2025, las empresas esperan que los profesionales de QA demuestren no solo conocimiento de pruebas, sino también competencia en codificación, comprensión de diseño de sistemas y fuertes habilidades de comunicación. Ya sea que estés aplicando a tu primer rol de QA o apuntando a una posición senior de SDET, la preparación completa es esencial.

Esta guía cubre todo lo que necesitas para sobresalir en tu entrevista QA: preguntas técnicas comunes con respuestas detalladas, desafíos de codificación prácticos, problemas de diseño de sistemas específicos para testing y estrategias de entrevistas conductuales.

Visión General del Proceso de Entrevista

La mayoría de las entrevistas QA siguen un proceso de múltiples etapas:

Etapa 1: Screening Telefónico/Video (30-45 min)

  • Conversación con reclutador o hiring manager
  • Revisión de antecedentes, evaluación de motivación
  • Preguntas técnicas de alto nivel
  • Discusión de logística y compensación

Etapa 2: Screen Técnico Telefónico (45-60 min)

  • Desafío de codificación o sesión de live coding
  • Preguntas de fundamentos de testing
  • Discusión de framework de automatización
  • Competencia en herramientas y tecnología

Etapa 3: Entrevista On-site o Panel Virtual (3-5 horas)

  • Múltiples rondas de entrevistas:
    • Deep-dive técnico: Codificación avanzada, diseño de frameworks
    • Diseño de sistemas: Arquitectura y estrategia de testing
    • Conductual: Fit del equipo, comunicación, experiencias pasadas
    • Ejercicio práctico: Escenario de testing del mundo real

Etapa 4: Discusión Final

  • Reunión con senior leadership o director
  • Evaluación de fit cultural
  • Oportunidad para hacer preguntas estratégicas
  • Negociación de oferta

Timeline de Preparación: Asigna 4-6 semanas para preparación exhaustiva, con 10-15 horas por semana de estudio y práctica.

Parte 1: Preguntas Técnicas

Fundamentos de Testing

Para conocimientos más profundos sobre fundamentos de testing, revisa Principios de Testing y Comparación de Enfoques de Testing.

P: ¿Cuál es la diferencia entre verificación y validación?

Respuesta:

  • Verificación: “¿Estamos construyendo el producto correctamente?” Verifica si el producto cumple especificaciones y requisitos. Se enfoca en el proceso.
  • Validación: “¿Estamos construyendo el producto correcto?” Verifica si el producto cumple las necesidades del usuario y resuelve el problema previsto. Se enfoca en el producto.

Ejemplo:

  • Verificación: Verificar que el botón de login está colocado donde indica la spec de diseño
  • Validación: Confirmar que el flujo de login realmente permite a los usuarios acceder a sus cuentas exitosamente

P: Explica la diferencia entre smoke, sanity y regression testing (como se discute en From Manual to Automation: Complete Transition Guide for QA Engineers).

Respuesta:

  • Smoke testing (como se discute en Functional Testing: A Comprehensive Guide from A to Z): Pruebas rápidas y superficiales de funcionalidad crítica para verificar estabilidad del build. “¿Podemos proceder con testing?” Usualmente 20-30 minutos.
  • Sanity testing (como se discute en Smoke vs Sanity vs Regression Testing: What’s the Difference?): Verificación rápida de funcionalidad específica después de una corrección de bug o cambio menor. Estrecho y profundo para un área.
  • Regression testing: Testing completo para asegurar que nuevos cambios no han roto funcionalidad existente. Puede automatizarse y ejecutarse frecuentemente.

P: ¿Qué es la pirámide de testing y por qué es importante?

Respuesta: La pirámide de testing es una estrategia de testing que enfatiza:

  • Base (más grande): Unit tests - Rápidos, baratos, muchos (70%)
  • Medio: Integration/API tests - Velocidad y costo moderados (20%)
  • Top (más pequeño): E2E/UI tests - Lentos, costosos, pocos (10%)

Importancia:

  • Eficiencia de costo: Unit tests son más rápidos y baratos de mantener
  • Feedback más rápido: Unit tests rápidos atrapan bugs temprano
  • Estabilidad: Menos E2E tests frágiles significa CI/CD más confiable
  • Cobertura balanceada: Cada capa prueba diferentes aspectos

P: ¿Cómo priorizas casos de prueba cuando el tiempo es limitado?

Respuesta: Usa priorización de testing basada en riesgo:

  1. Critical path primero: Features con las que los usuarios interactúan más (login, checkout, search)
  2. Alto impacto, alta probabilidad: Features que se rompen a menudo y causan problemas mayores
  3. Cambios recientes: Áreas de desarrollo activo
  4. Problemas reportados por clientes: Bugs encontrados previamente y funcionalidad relacionada
  5. Requisitos de cumplimiento: Seguridad, accesibilidad, mandatos legales

Framework: Riesgo = Probabilidad × Impacto. Prueba primero items de mayor riesgo.

Automatización y Codificación

P: ¿Cuáles son las ventajas y desventajas de Selenium vs. Playwright/Cypress?

Respuesta:

Selenium:

  • Pros: Ecosistema maduro, soporta muchos lenguajes, gran comunidad, cross-browser
  • Contras: Ejecución más lenta, requiere waits explícitos, más pruebas flaky, sin paralelización integrada

Playwright/Cypress:

  • Pros: Arquitectura moderna, auto-wait, ejecución más rápida, mejor debugging, paralelización integrada
  • Contras: Herramientas más nuevas (comunidad más pequeña), soporte de lenguaje limitado (Cypress: solo JS), limitaciones de navegador (Cypress: sin Safari)

Recomendación: Apps web modernas se benefician de Playwright/Cypress. Sistemas legacy o Java shops pueden preferir Selenium.

P: Explica el patrón Page Object Model (POM). ¿Por qué usarlo?

Respuesta: POM es un patrón de diseño que crea un repositorio de objetos para elementos web, separando lógica de prueba de código específico de página.

Estructura:

# page_objects/login_page.py
class LoginPage:
    def __init__(self, driver):
        self.driver = driver
        self.username_field = (By.ID, "username")
        self.password_field = (By.ID, "password")
        self.login_button = (By.ID, "submit")

    def login(self, username, password):
        self.driver.find_element(*self.username_field).send_keys(username)
        self.driver.find_element(*self.password_field).send_keys(password)
        self.driver.find_element(*self.login_button).click()

# tests/test_login.py
def test_valid_login(login_page):
    login_page.login("user@example.com", "password123")
    assert login_page.is_logged_in()

Beneficios:

  • Mantenibilidad: Los cambios de locator solo actualizan el page object
  • Reutilización: Múltiples pruebas usan los mismos métodos de página
  • Legibilidad: Las pruebas se leen como acciones de usuario, no pasos técnicos
  • Reducción de duplicación: Principio DRY (Don’t Repeat Yourself)

Testing de API

P: ¿Cuál es la diferencia entre APIs SOAP y REST?

Respuesta:

AspectoRESTSOAP
ProtocoloEstilo arquitectónico (usa HTTP)Protocolo estricto
Formato de datosJSON, XML (flexible)Solo XML
RendimientoMás rápido, ligeroMás lento, más overhead
Caso de usoApps web/móviles modernasEnterprise, sistemas legacy, WS-Security
EstadoStatelessPuede ser stateful o stateless

Diferencias de testing:

  • REST: Probar métodos HTTP (GET, POST, PUT, DELETE), status codes, schema JSON
  • SOAP: Probar WSDL, validación de schema XML, envelopes SOAP

P: ¿Cómo pruebas una API?

Respuesta: 1. Testing funcional:

  • Verificar respuestas correctas para inputs válidos
  • Probar operaciones CRUD
  • Validar status codes de respuesta (200, 201, 400, 404, 500)
  • Verificar schema de respuesta y tipos de datos
  • Probar autenticación y autorización

2. Testing negativo:

  • Inputs inválidos (tipos de datos incorrectos, campos requeridos faltantes)
  • Tokens de autenticación inválidos
  • Valores de boundary
  • Solicitudes mal formadas

3. Testing de rendimiento:

  • Tiempo de respuesta bajo carga
  • Comportamiento de rate limiting
  • Manejo de solicitudes concurrentes

4. Testing de seguridad:

  • Intentos de SQL injection, XSS
  • Intentos de bypass de autenticación
  • Exposición de datos sensibles

Parte 2: Desafíos de Codificación Práctica

Desafío 1: Validador de Palíndromo

Problema: Escribe una función para verificar si una cadena es un palíndromo (se lee igual hacia adelante y hacia atrás). Ignora espacios, puntuación y mayúsculas.

Ejemplos:

  • isPalindrome("A man a plan a canal Panama") → True
  • isPalindrome("race a car") → False

Solución (Python):

def is_palindrome(s):
    # Remover caracteres no alfanuméricos y convertir a minúsculas
    cleaned = ''.join(char.lower() for char in s if char.isalnum())

    # Verificar si la cadena limpiada es igual a su reverso
    return cleaned == cleaned[::-1]

# Casos de prueba
assert is_palindrome("A man a plan a canal Panama") == True
assert is_palindrome("race a car") == False
assert is_palindrome("") == True
assert is_palindrome("a") == True

Complejidad temporal: O(n), Complejidad espacial: O(n)

Desafío 2: Encontrar Elementos Duplicados

Problema: Dado un array de enteros, encuentra todos los elementos que aparecen más de una vez.

Ejemplo:

  • Input: [1, 2, 3, 2, 4, 5, 3]
  • Output: [2, 3]

Solución (Python):

def find_duplicates(nums):
    seen = set()
    duplicates = set()

    for num in nums:
        if num in seen:
            duplicates.add(num)
        else:
            seen.add(num)

    return list(duplicates)

# Casos de prueba
assert set(find_duplicates([1, 2, 3, 2, 4, 5, 3])) == {2, 3}
assert find_duplicates([1, 2, 3, 4]) == []
assert find_duplicates([1, 1, 1, 1]) == [1]

Parte 3: Diseño de Sistemas para QA

Pregunta: Diseña un framework de automatización de pruebas para una aplicación de e-commerce

Enfoque de entrevista: Clarifica requisitos, discute arquitectura, explica trade-offs.

Preguntas de clarificación:

  • ¿Tipo de aplicación? (Web, móvil, API?)
  • ¿Tamaño de equipo y nivel de habilidad?
  • ¿Infraestructura existente (CI/CD, cloud)?
  • ¿Prioridades de testing (regression, smoke, end-to-end)?

Diseño:

1. Capas de arquitectura:

┌─────────────────────────────────────┐
│      Casos de Prueba                │  (Lógica de negocio tests)
├─────────────────────────────────────┤
│      Page Objects                   │  (Abstracción UI)
├─────────────────────────────────────┤
│   Utilidades y Helpers              │  (Funciones comunes)
├─────────────────────────────────────┤
│ Configuración y Gestión de Datos    │  (Config files, test data)
├─────────────────────────────────────┤
│    Reportes y Logging               │  (Test results, logs)
└─────────────────────────────────────┘

2. Elecciones de tecnología:

  • Lenguaje: Python (legibilidad, bibliotecas ricas)
  • Framework: Pytest (fixtures, plugins, parametrización)
  • Automatización web: Playwright (moderno, rápido, auto-wait)
  • Testing de API: Biblioteca Requests
  • Reportes: Allure (visual, reportes interactivos)
  • CI/CD: GitHub Actions o Jenkins
  • Test data: Archivos JSON o fixtures de base de datos

3. Características clave:

  • Page Object Model para UI tests
  • Pruebas data-driven (parametrización)
  • Ejecución paralela (pytest-xdist)
  • Mecanismo de retry inteligente para pruebas flaky
  • Captura de screenshot/video en fallas
  • Configuración basada en entorno (dev, staging, prod)
  • Integración con pipeline CI/CD

4. Estructura de carpetas:

automation-framework/
├── tests/
│   ├── ui/
│   ├── api/
│   └── integration/
├── page_objects/
├── utils/
│   ├── driver_factory.py
│   ├── config.py
│   └── helpers.py
├── test_data/
│   ├── users.json
│   └── products.json
├── reports/
├── requirements.txt
├── pytest.ini
└── README.md

Parte 4: Preguntas Conductuales

Las preguntas conductuales evalúan fit cultural, comunicación y experiencias pasadas. Usa el método STAR: Situación, Tarea, Acción, Resultado.

Pregunta: Cuéntame sobre una vez que encontraste un bug crítico justo antes del lanzamiento

Ejemplo de respuesta (formato STAR):

Situación: Una semana antes de un lanzamiento importante de producto, estaba conduciendo testing de regresión final para nuestro feature de procesamiento de pagos.

Tarea: Necesitaba asegurar que todos los flujos de pago funcionaran correctamente a través de diferentes métodos de pago y monedas.

Acción: Mientras probaba casos extremos, descubrí que los reembolsos para pedidos parcialmente enviados se calculaban incorrectamente, resultando en cobros excesivos a clientes. Inmediatamente documenté el bug con pasos de reproducción, screenshots y análisis de impacto. Escalé al product manager y equipo de desarrollo, explicando claramente el riesgo financiero y reputacional de lanzar con este bug.

Resultado: El equipo decidió retrasar el lanzamiento por 3 días para corregir el bug. Después de la corrección, lo verifiqué y lanzamos exitosamente. Mi testing proactivo previno un estimado de $50K en reembolsos incorrectos y potenciales problemas de confianza del cliente. El equipo implementó pruebas automatizadas adicionales para cálculos de reembolsos para prevenir problemas similares.

Puntos clave:

  • Demuestra exhaustividad en testing
  • Muestra comunicación clara y escalación
  • Destaca conciencia de impacto de negocio
  • Menciona mejora de proceso (automatización)

Pregunta: Describe una situación donde no estuviste de acuerdo con un desarrollador sobre un bug

Ejemplo de respuesta:

Situación: Reporté un bug donde los usuarios no podían subir fotos de perfil mayores de 2MB, pero el mensaje de error decía “Formato de archivo inválido” en lugar de indicar el problema de tamaño.

Tarea: El desarrollador lo marcó como “Funcionando Como Se Pretende” porque la funcionalidad trabajaba (archivos eran rechazados), pero yo creía que el mensaje de error engañoso era una mala experiencia de usuario.

Acción: No argumenté emocionalmente. En su lugar:

  1. Reuní analytics de usuarios mostrando que 15% de subidas excedían 2MB
  2. Compartí comparación de screenshot de nuestro error vs. apps competidoras con mensajería clara
  3. Estimé carga de tickets de soporte al cliente de usuarios confundidos
  4. Propuse una corrección simple: actualizar el mensaje de error

Resultado: El desarrollador acordó después de ver los datos. Corregimos el mensaje de error, y los tickets de soporte al cliente relacionados con subidas de perfil disminuyeron 30% en el mes siguiente. Esta experiencia me enseñó la importancia de discusiones basadas en datos y enfocarse en impacto de usuario.

Puntos clave:

  • Muestra habilidades de resolución de conflictos
  • Usa datos para apoyar posición
  • Mantiene relación profesional
  • Se enfoca en experiencia de usuario e impacto de negocio

Conclusión

La preparación para entrevistas QA requiere un enfoque multifacético: fundamentos técnicos sólidos, práctica de codificación, pensamiento de sistemas y habilidades de comunicación. La clave del éxito es la preparación consistente y enfocada durante 4-6 semanas.

Tu plan de preparación de 4 semanas:

Semana 1: Revisar fundamentos de testing, preguntas de entrevista comunes Semana 2: Practicar desafíos de codificación (LeetCode Easy-Medium, scripts de automatización) Semana 3: Estudiar diseño de sistemas, revisar frameworks y arquitectura Semana 4: Mock interviews, práctica de preguntas conductuales, investigación de empresa

Recuerda: Las entrevistas son conversaciones bidireccionales. Mientras demuestras tus habilidades, también evalúa si la empresa, equipo y rol se alinean con tus metas de carrera. Para orientación sobre tu dirección general de carrera, consulta el Roadmap del Ingeniero QA 2025. ¡Buena suerte!