Guía de preparación para la entrevista de Test Engineer: Preguntas, estrategias y lo que realmente buscan los gerentes de contratación

Introducción

Aproximadamente 150.750 ingenieros trabajan en especializaciones de ingeniería relacionadas en Estados Unidos, ganando un salario mediano de 117.750 USD — sin embargo, el campo proyecta solo alrededor de 9.300 vacantes anuales, lo que significa que cada entrevista de Test Engineer que consigas tiene un peso considerable [1][8].

Puntos clave

• Las preguntas conductuales dominan la primera ronda. Los gerentes de contratación quieren ver cómo has manejado defectos que llegaron a producción, requisitos ambiguos y resistencia de los desarrolladores — no solo que sabes cómo se ve un plan de pruebas.
• La profundidad técnica importa más que la amplitud. Los entrevistadores exploran tu comprensión de técnicas de diseño de pruebas, frameworks de automatización y gestión del ciclo de vida de defectos en lugar de pedirte que recites palabras de moda [12].
• El método STAR es tu mejor aliado para estructurar respuestas. Las respuestas estructuradas superan consistentemente a las anécdotas divagantes, especialmente al describir escenarios de prueba complejos [11].
• Hacer preguntas agudas señala experiencia. Las preguntas que haces sobre procesos de release, infraestructura de pruebas y cultura de calidad revelan más sobre tu nivel de experiencia que tu currículum.
• La preparación para preguntas situacionales separa a los buenos candidatos de los excelentes. Espera escenarios hipotéticos que involucren plazos ajustados, incidentes en producción y conflictos multifuncionales.

¿Qué preguntas conductuales se hacen en entrevistas de Test Engineer?

Las preguntas conductuales revelan cómo has rendido realmente bajo las presiones únicas de la ingeniería de pruebas — no cómo crees que rendirías. Los entrevistadores las usan para evaluar tu juicio, habilidades de colaboración y mentalidad de calidad [12]. Prepara respuestas usando el método STAR (Situación, Tarea, Acción, Resultado) para cada una de estas preguntas comunes [11]:

1. "Cuéntame sobre una ocasión en que un defecto crítico llegó a producción. ¿Qué pasó y qué hiciste?"

Lo que evalúan: Responsabilidad, análisis de causa raíz e instintos de mejora de procesos.

Marco: Describe el defecto y su impacto (Situación/Tarea). Presenta tu investigación — ¿lo rastreaste a una brecha en la cobertura de pruebas, una discrepancia de entorno o una malinterpretación de requisitos? (Acción). Termina con el cambio de proceso que implementaste para prevenir la recurrencia (Resultado).

2. "Describe una situación en la que no estuviste de acuerdo con un desarrollador sobre si algo era un error."

Lo que evalúan: Habilidades de comunicación, credibilidad técnica y resolución de conflictos.

Marco: Establece el desacuerdo específico — ¿fue un comportamiento de UI, un caso límite o una interpretación de especificación? Explica cómo recopilaste evidencia (logs, documentos de requisitos, datos de comportamiento del usuario) y cómo alcanzaste una resolución. Evita enmarcarlo como "yo tenía razón, ellos estaban equivocados".

3. "Cuéntame sobre una ocasión en que tuviste que probar una funcionalidad con requisitos incompletos o ambiguos."

Lo que evalúan: Ingenio y tu enfoque para las pruebas basadas en riesgo.

Marco: Describe la ambigüedad. Explica cómo identificaste las brechas — ¿formulaste preguntas aclaratorias, construiste una tabla de decisión o creaste cartas de prueba exploratoria? Muestra que no esperaste especificaciones perfectas; impulsaste la claridad.

4. "Dame un ejemplo de cuando mejoraste un proceso de prueba o redujiste el tiempo de ejecución de pruebas."

Lo que evalúan: Mentalidad de mejora continua e iniciativa técnica.

Marco: Cuantifica el antes y después. "Reduje el tiempo de ejecución de la suite de regresión de 6 horas a 90 minutos paralelizando la ejecución y eliminando casos de prueba redundantes" es mucho más fuerte que "hice las pruebas más rápidas".

5. "Describe una ocasión en que tuviste que aprender una nueva herramienta o tecnología rápidamente para cumplir con la fecha límite de un proyecto."

Lo que evalúan: Adaptabilidad y velocidad de aprendizaje.

Marco: Nombra la herramienta específica (Selenium, Cypress, JMeter, un framework propietario). Explica tu enfoque de aprendizaje — documentación, trabajo en pareja con un colega, construcción de una prueba de concepto. Vincúlalo con el resultado del proyecto.

6. "Cuéntame sobre una ocasión en que tuviste que abogar por la calidad cuando el equipo quería recortar las pruebas."

Lo que evalúan: Firmeza y habilidades de comunicación de riesgos.

Marco: Aquí muestras que entiendes que abogar por la calidad no se trata de decir "no" — se trata de hacer visible el riesgo. Describe cómo comunicaste los riesgos específicos de lanzar sin pruebas adecuadas y qué compromiso o resultado se obtuvo.

7. "Describe una situación en la que colaboraste con equipos multifuncionales (desarrolladores, PMs, DevOps) para lanzar una versión."

Lo que evalúan: Trabajo en equipo y tu comprensión de dónde encajan las pruebas en el SDLC.

Marco: Destaca tus contribuciones específicas — ¿coordinaste entornos de prueba con DevOps, alineaste planes de prueba con las prioridades del PM o trabajaste con desarrolladores en la cobertura de pruebas unitarias? Muestra que operas como un socio de calidad, no como un portero.

¿Qué preguntas técnicas deben preparar los Test Engineers?

Las entrevistas técnicas para Test Engineers exploran tanto tu conocimiento teórico como tu experiencia práctica con metodologías de prueba, herramientas y prácticas de ingeniería [12]. Esto es lo que puedes esperar:

1. "Guíame a través de cómo diseñarías un plan de pruebas para un nuevo endpoint de API."

Lo que evalúan: Pensamiento sistemático de diseño de pruebas.

Orientación: Cubre pruebas funcionales (entradas válidas, valores límite, códigos de error), pruebas negativas (solicitudes malformadas, fallas de autenticación, limitación de tasa), consideraciones de rendimiento y validación de datos. Menciona códigos de estado HTTP específicos que verificarías. Los entrevistadores quieren ver que piensas más allá del camino feliz.

2. "¿Cuál es la diferencia entre partición de equivalencia, análisis de valores límite y pruebas con tablas de decisión? ¿Cuándo usarías cada una?"

Lo que evalúan: Conocimiento de técnicas formales de diseño de pruebas [3].

Orientación: Da ejemplos concretos. Partición de equivalencia para campos de entrada con rangos definidos, análisis de valores límite para errores de uno más/uno menos en límites numéricos, tablas de decisión para reglas de negocio complejas con múltiples condiciones. Puntos extra por mencionar pruebas de transición de estado o pruebas por pares cuando sea apropiado.

3. "Explica tu enfoque de la arquitectura de automatización de pruebas. ¿Cómo decides qué automatizar?"

Lo que evalúan: Madurez de estrategia de automatización, no solo capacidad de scripting.

Orientación: Discute la pirámide de automatización de pruebas (unitarias → integración → E2E). Explica tus criterios para candidatos de automatización: rutas de regresión de alta frecuencia, funcionalidades estables, escenarios dirigidos por datos. Reconoce lo que no debe automatizarse — pruebas exploratorias, UI que cambia rápidamente, validaciones únicas. Nombra frameworks específicos que hayas usado (Selenium WebDriver, Cypress, pytest, TestNG, Robot Framework) y explica tus decisiones arquitectónicas (Page Object Model, basado en palabras clave, dirigido por datos).

4. "¿Cómo abordas las pruebas de rendimiento? ¿Qué métricas importan?"

Lo que evalúan: Comprensión de pruebas no funcionales.

Orientación: Distingue entre pruebas de carga, pruebas de estrés, pruebas de resistencia y pruebas de pico. Discute métricas clave: tiempo de respuesta (p50, p95, p99), throughput, tasa de errores y utilización de recursos. Menciona herramientas como JMeter, Gatling o k6. Explica cómo estableces líneas base y defines umbrales aceptables.

5. "Describe el ciclo de vida de un defecto. ¿Qué información debe contener un informe de error bien escrito?"

Lo que evalúan: Disciplina de procesos y claridad de comunicación.

Orientación: Recorre: Nuevo → Asignado → En Progreso → Corregido → Verificado → Cerrado (con ramificaciones de Reabierto y Diferido). Para informes de errores: pasos para reproducir, comportamiento esperado vs. real, detalles del entorno, severidad/prioridad, capturas de pantalla o logs, y tasa de reproducibilidad. Enfatiza que la calidad de un informe de error impacta directamente la velocidad de corrección.

6. "¿Cuál es tu experiencia con pipelines de CI/CD y cómo se integran las pruebas en ellos?"

Lo que evalúan: Conocimiento moderno de DevOps y mentalidad de shift-left testing [6].

Orientación: Describe cómo has integrado pruebas automatizadas en pipelines de Jenkins, GitLab CI, GitHub Actions o Azure DevOps. Discute el gating por etapa de prueba — qué pruebas se ejecutan en cada commit (unitarias, smoke) vs. nocturnamente (regresión completa, rendimiento). Menciona estrategias de gestión de pruebas inestables.

7. "¿Cómo probarías una página de inicio de sesión?"

Lo que evalúan: Profundidad de pensamiento ante una pregunta engañosamente simple.

Orientación: Esta pregunta clásica separa a los candidatos junior de los senior. Ve más allá de "credenciales válidas, credenciales inválidas". Cubre: inyección SQL, XSS, protección contra fuerza bruta, gestión de sesiones, enmascaramiento de contraseñas, comportamiento de CAPTCHA, flujos de autenticación multifactor, accesibilidad (lectores de pantalla, navegación por teclado), localización y rendimiento bajo inicios de sesión concurrentes.

¿Qué preguntas situacionales hacen los entrevistadores de Test Engineer?

Las preguntas situacionales presentan escenarios hipotéticos para evaluar tu juicio y enfoque de resolución de problemas. A diferencia de las preguntas conductuales, estas evalúan cómo manejarías situaciones que quizás no hayas encontrado antes [12].

1. "Estás a dos días del lanzamiento y descubres un defecto de severidad 2 en un flujo de trabajo principal. El PM quiere lanzar a tiempo. ¿Qué haces?"

Enfoque: Demuestra pensamiento basado en riesgo. Cuantifica el impacto del defecto — ¿a cuántos usuarios afecta? ¿Hay una solución alternativa? Presenta al PM opciones: lanzar con un problema conocido y un cronograma de hotfix, retrasar el lanzamiento, o lanzar con un feature flag que desactive el flujo de trabajo afectado. Tu trabajo es hacer visible el riesgo, no tomar la decisión unilateralmente.

2. "Heredas una suite de pruebas legacy con 3.000 pruebas automatizadas. El treinta por ciento son inestables, y nadie sabe qué cubre la mitad de ellas. ¿Cómo lo abordas?"

Enfoque: Resiste la urgencia de decir "reescribir todo". Esboza una estrategia de triaje: pon en cuarentena las pruebas inestables inmediatamente para que dejen de bloquear el pipeline. Analiza los patrones de falla para categorizar las pruebas inestables (problemas de temporización, dependencias de entorno, conflictos de datos de prueba). Mapea las pruebas restantes a los requisitos actuales para identificar pruebas huérfanas. Prioriza la estabilización de pruebas que cubren flujos de negocio críticos. Esta pregunta evalúa tu pragmatismo.

3. "Un desarrollador te dice que su código no necesita pruebas porque escribió pruebas unitarias con un 90 % de cobertura. ¿Cómo respondes?"

Enfoque: Reconoce el valor de sus pruebas unitarias — no las desestimes. Luego explica lo que las pruebas unitarias no cubren: puntos de integración, flujos de trabajo de usuario de extremo a extremo, comportamiento específico del entorno, requisitos no funcionales y casos límite que emergen de la interacción entre componentes. Enmárcalo como capas complementarias de calidad, no como enfoques en competencia.

4. "Tu equipo está haciendo la transición de pruebas manuales a automatización. ¿Cómo liderarías esta transición?"

Enfoque: Comienza con un piloto — elige un área de regresión estable y de alto valor. Selecciona un framework que coincida con las habilidades del equipo (no fuerces Python a un equipo de Java). Establece estándares de codificación y procesos de revisión para el código de pruebas. Define métricas de éxito más allá del "número de pruebas automatizadas" — enfócate en la tasa de detección de defectos, reducción del tiempo de ejecución y confianza del equipo. Planifica para la realidad de que las pruebas exploratorias manuales siguen siendo esenciales.

5. "Te asignan a un proyecto que usa una pila tecnológica con la que nunca has trabajado. ¿Cómo preparas tus pruebas?"

Enfoque: Describe una preparación estructurada: revisar la documentación de arquitectura, observar a un desarrollador durante un recorrido por el código, identificar los puntos de integración más riesgosos y comenzar con pruebas exploratorias antes de escribir casos de prueba formales. Menciona que tus habilidades fundamentales de prueba — análisis de riesgos, diseño de pruebas, investigación de defectos — son transferibles entre pilas tecnológicas.

¿Qué buscan los entrevistadores en candidatos a Test Engineer?

Los gerentes de contratación evalúan a los candidatos de Test Engineer a través de varias dimensiones, y la habilidad técnica es solo una de ellas [12].

Criterios de evaluación fundamentales:

• Pensamiento sistemático: ¿Puedes descomponer un sistema complejo en componentes probables e identificar áreas de riesgo sin que te digan dónde buscar?
• Claridad de comunicación: Los Test Engineers son traductores entre la realidad técnica y el riesgo de negocio. Tu capacidad para articular el impacto de defectos a interesados no técnicos importa enormemente.
• Competencia en automatización: La mayoría de los puestos ahora esperan habilidades prácticas de automatización. Los entrevistadores evalúan si puedes diseñar frameworks de prueba sostenibles, no solo scripts de grabar y reproducir [4][5].
• Responsabilidad de calidad: Los mejores candidatos tratan la calidad como una responsabilidad compartida del equipo, no como una fase que ocurre después del desarrollo. Hablan de shift-left, participación en revisiones de diseño e influencia en la testabilidad.

Señales de alerta que hunden a los candidatos:

• Describir las pruebas como puramente "encontrar errores" en lugar de prevenirlos
• Incapacidad para explicar por qué elegiste un enfoque de prueba específico
• Culpar a los desarrolladores por los defectos en lugar de describir soluciones colaborativas
• No tener curiosidad sobre el producto, sus usuarios o su contexto de negocio

Lo que diferencia a los mejores candidatos: Los mejores candidatos a Test Engineer preguntan sobre los desafíos de calidad actuales del equipo antes de que les hagan una sola pregunta. Traen ejemplos con resultados medibles — "reduje los defectos escapados en un 40 %" supera a "mejoré la calidad". Demuestran que piensan en las pruebas como una disciplina de ingeniería, no como una actividad de casillas de verificación. Una licenciatura es el requisito educativo típico de entrada [7], pero la capacidad demostrada de resolución de problemas y la experiencia práctica tienen un peso significativo en las entrevistas.

¿Cómo debe usar un Test Engineer el método STAR?

El método STAR (Situación, Tarea, Acción, Resultado) transforma respuestas vagas de entrevista en narrativas convincentes y estructuradas [11]. Aquí tienes ejemplos completos adaptados a escenarios de Test Engineer:

Ejemplo 1: Reducción del tiempo de ciclo de pruebas de regresión

Situación: "La suite de regresión de nuestro equipo tardaba 8 horas en ejecutarse manualmente, lo que significaba que solo podíamos ejecutar la regresión completa una vez por sprint. Los defectos se descubrían regularmente después del deployment."

Tarea: "Me encargaron reducir el tiempo del ciclo de regresión para que pudiéramos ejecutarlo antes de cada release candidate, no solo una vez por sprint."

Acción: "Analicé nuestros 450 casos de prueba manuales y los categoricé por riesgo y frecuencia de ejecución. Automaticé los 120 casos de mayor prioridad usando Selenium WebDriver con una arquitectura Page Object Model, los integré en nuestro pipeline de Jenkins y configuré la ejecución paralela en tres configuraciones de navegador. También identifiqué 80 casos de prueba que eran redundantes o probaban funcionalidades obsoletas y los eliminé."

Resultado: "La ejecución de regresión bajó de 8 horas a 45 minutos. Detectamos 12 defectos críticos en el primer mes que previamente habrían llegado a producción. La confianza del equipo en la calidad del release aumentó de manera medible — pasamos de un rollback al mes a cero durante el trimestre siguiente."

Ejemplo 2: Navegando requisitos ambiguos

Situación: "Recibimos una solicitud de funcionalidad para un motor de precios dinámicos, pero el documento de requisitos eran tres puntos con viñetas sin criterios de aceptación. El desarrollo estaba programado para comenzar en una semana."

Tarea: "Necesitaba crear una estrategia de prueba integral a pesar de las especificaciones incompletas."

Acción: "Programé un taller de requisitos con el PM, el desarrollador líder y un analista de negocio. Preparé una tabla de decisión con 15 escenarios de precios que identifiqué a partir de análisis de competidores e historias de usuario. Durante la sesión, descubrimos 8 casos límite que el PM no había considerado — incluyendo reglas de redondeo de moneda y ventanas de precios dependientes de zona horaria. Documenté estos como criterios de aceptación probables y los compartí con el equipo antes de que comenzara el desarrollo."

Resultado: "El desarrollo comenzó con criterios de aceptación claros, lo que redujo el recuento de defectos durante las pruebas en aproximadamente un 60 % en comparación con funcionalidades similares. El PM adoptó mi enfoque de tabla de decisión para futuras especificaciones de funcionalidades, y se convirtió en parte estándar de nuestro proceso de refinamiento."

Ejemplo 3: Abogando por la calidad bajo presión

Situación: "Tres días antes de un lanzamiento importante de producto, nuestras pruebas de rendimiento revelaron que la API de checkout se degradaba significativamente con 500 usuarios concurrentes — muy por debajo de nuestro tráfico esperado el día del lanzamiento de 2.000."

Tarea: "Necesitaba comunicar este riesgo a la dirección y ayudar al equipo a resolverlo sin descarrilar el lanzamiento."

Acción: "Creé un resumen de riesgo de una página mostrando los tiempos de respuesta proyectados con la carga del día de lanzamiento, el impacto estimado en ingresos de una demora de 10 segundos en el checkout, y dos opciones de mitigación: un retraso de 48 horas para optimización o lanzar con limitación de tráfico y un plan de escalado. Presenté esto al VP de Ingeniería junto con el desarrollador líder."

Resultado: "La dirección eligió el retraso de 48 horas. El equipo de desarrollo optimizó las consultas de base de datos que señalé, y volvimos a probar exitosamente con 3.000 usuarios concurrentes. El lanzamiento se realizó sin incidentes, y el VP citó posteriormente las pruebas de rendimiento como la razón por la que evitamos una caída pública."

¿Qué preguntas debe hacer un Test Engineer al entrevistador?

Las preguntas que haces revelan tu nivel de experiencia y prioridades. Estas demuestran experiencia genuina de Test Engineer:

1. "¿Cómo se ve tu pirámide de automatización de pruebas actual? ¿Qué porcentaje de tus pruebas son unitarias, de integración y de extremo a extremo?" — Muestra que entiendes la estrategia de automatización, no solo la ejecución.

2. "¿Cómo se integran las pruebas en tu pipeline de CI/CD? ¿Hay quality gates automatizados antes del deployment?" — Señala que piensas en las pruebas como parte del proceso de entrega.

3. "¿Cuál es el enfoque del equipo con respecto a las pruebas inestables? ¿Tienen un proceso de cuarentena?" — Esta es una pregunta que solo hace alguien que ha lidiado con automatización del mundo real.

4. "¿Cómo se gestionan los entornos de prueba? ¿Quién es responsable del aprovisionamiento de entornos y la preparación de datos?" — Los problemas de entorno son el asesino de productividad número uno para los Test Engineers. Esto muestra que lo sabes.

5. "¿Cuál es la proporción de pruebas exploratorias manuales frente a pruebas automatizadas en el equipo?" — Demuestra que valoras ambos enfoques y entiendes sus roles complementarios.

6. "¿Cómo maneja el equipo los defectos que llegan a producción? ¿Hay un proceso de post-mortem sin culpas?" — Revela tu interés en la cultura de calidad, no solo en las herramientas de calidad.

7. "¿Cuáles son los mayores desafíos de calidad que enfrenta el equipo en este momento?" — Esto te posiciona como alguien que ya está pensando en cómo contribuir, y te da información crítica sobre la realidad del puesto.

Puntos clave

Las entrevistas de Test Engineer evalúan una combinación de profundidad técnica, pensamiento sistemático y habilidades de comunicación. Tu preparación debe enfocarse en tres pilares: dominar las respuestas conductuales con el método STAR [11], demostrar experiencia técnica genuina en diseño de pruebas y automatización, y mostrar que piensas en la calidad como una disciplina de ingeniería.

Practica tus respuestas en voz alta — las respuestas estructuradas se sienten poco naturales hasta que las has ensayado. Cuantifica tu impacto siempre que sea posible: porcentajes, tiempo ahorrado, defectos detectados, cobertura mejorada. Investiga el producto de la empresa antes de la entrevista y ve preparado con escenarios de prueba específicos que quieras explorar.

El salario mediano de Test Engineer de 117.750 USD [1] refleja el valor que las organizaciones otorgan a este puesto. Demuestra en tu entrevista que vales la inversión presentándote preparado, específico y genuinamente curioso sobre los desafíos de calidad del equipo.

¿Listo para asegurarte de que tu currículum te lleve a la etapa de entrevista? El constructor de currículums impulsado por IA de Resume Geni ayuda a los Test Engineers a destacar las habilidades técnicas y logros medibles que buscan los gerentes de contratación.

Preguntas frecuentes

¿Cuántos puestos de Test Engineer hay disponibles en Estados Unidos?

Aproximadamente 150.750 profesionales trabajan en esta categoría de especialización de ingeniería, con alrededor de 9.300 vacantes anuales proyectadas hasta 2034 [1][8].

¿Qué salario debo esperar como Test Engineer?

El salario anual mediano es de 117.750 USD, con un rango que va desde 62.840 USD en el percentil 10 hasta 183.510 USD en el percentil 90, dependiendo de la especialización, ubicación y experiencia [1].

¿Qué educación necesito para ser Test Engineer?

Una licenciatura es el requisito educativo típico de entrada, y la mayoría de los puestos no requieren experiencia laboral previa ni capacitación en el puesto [7].

¿Qué tan rápido está creciendo el campo de Test Engineer?

La tasa de crecimiento proyectada es del 2,1 % de 2024 a 2034, representando aproximadamente 3.300 nuevos puestos durante la década [8].

¿Cuál es el error más común en las entrevistas de Test Engineer?

Enfocarse exclusivamente en herramientas y frameworks sin demostrar pensamiento de diseño de pruebas. Los entrevistadores quieren saber por qué elegiste un enfoque, no solo que puedes usar Selenium [12].

¿Debo prepararme para preguntas de programación en una entrevista de Test Engineer?

Sí. Muchos puestos de Test Engineer requieren habilidades de automatización, y los entrevistadores frecuentemente piden a los candidatos que escriban o depuren scripts de prueba. Practica escribiendo código de prueba limpio y mantenible en tu lenguaje principal [4][5].

¿Cómo debo estructurar mis respuestas a preguntas conductuales?

Usa el método STAR: Situación, Tarea, Acción, Resultado. Este marco mantiene tus respuestas enfocadas, concisas y fáciles de seguir para los entrevistadores. Siempre termina con un resultado cuantificable cuando sea posible [11].

Referencias

[1] U.S. Bureau of Labor Statistics. "Occupational Employment and Wages: Test Engineer." https://www.bls.gov/oes/current/oes172199.htm

[3] O*NET OnLine. "Skills for Test Engineer." https://www.onetonline.org/link/summary/17-2199.00#Skills

[4] O*NET OnLine. "Technology Skills for Test Engineer." https://www.onetonline.org/link/summary/17-2199.00#Technology

[5] O*NET OnLine. "Knowledge for Test Engineer." https://www.onetonline.org/link/summary/17-2199.00#Knowledge

[6] O*NET OnLine. "Tasks for Test Engineer." https://www.onetonline.org/link/summary/17-2199.00#Tasks

[7] U.S. Bureau of Labor Statistics. "Occupational Outlook Handbook: How to Become One." https://www.bls.gov/ooh/occupation-finder.htm

[8] U.S. Bureau of Labor Statistics. "Employment Projections: 2022-2032 Summary." https://www.bls.gov/emp/

[11] Indeed Career Guide. "How to Use the STAR Method." https://www.indeed.com/career-advice/interviewing/how-to-use-the-star-interview-response-technique

[12] Glassdoor. "Glassdoor Interview Questions: Test Engineer." https://www.glassdoor.com/Interview/Test+Engineer-interview-questions-SRCH_KO0,13.htm