Ingeniero QA Preguntas de entrevista & Respuestas

Respuesta modelo

Durante las pruebas de regresión de una actualización del sistema de pago, noté que la conversión de divisas redondeaba incorrectamente en transacciones por debajo de $1. La suite de pruebas automatizadas pasó sin problemas porque todos los casos de prueba usaban importes superiores a $10. Lo descubrí mediante pruebas exploratorias: probé sistemáticamente los valores límite cercanos a cero y encontré que las transacciones de $0.99 o menos se redondeaban a $0.00 tras la conversión. La causa raíz era una división entera en lugar de división en punto flotante en la función de conversión. De haber llegado a producción, habría afectado aproximadamente al 15% de nuestras micro-transacciones, unas 8.000 operaciones diarias con una pérdida estimada de $3.200 al día en ingresos. Tras la corrección, añadí 20 casos de prueba de valores límite a la suite automatizada, cubriendo importes pequeños, importes cero y los máximos en cada divisa admitida.

Respuesta modelo

Nuestra suite de pruebas de extremo a extremo tardaba 3 horas en ejecutarse y bloqueaba cada fusión de pull request. Los desarrolladores optaban por omitir las pruebas o agrupar los PR para evitar la espera. Analicé la suite y detecté tres problemas: las pruebas se ejecutaban en secuencia en vez de en paralelo, el 30% eran redundantes (cubrían los mismos caminos de código) y las pruebas inestables provocaban que el 40% de las ejecuciones fallaran al primer intento. Contenerizé el entorno de pruebas para ejecutarlas en paralelo con 8 workers, eliminé 45 pruebas redundantes y puse en cuarentena 12 pruebas inestables mientras corregía sus causas raíz (en su mayoría condiciones de carrera y datos de prueba codificados en duro). El tiempo de ejecución bajó de 3 horas a 25 minutos, la inestabilidad pasó del 40% a menos del 2% y la frecuencia de fusión de PR por parte de los desarrolladores se duplicó. El equipo pasó de ver las pruebas como un obstáculo a confiar en ellas como una red de seguridad.

Respuesta modelo

Detecté que nuestra función de búsqueda devolvía resultados en un orden diferente cuando se ejecutaba la misma consulta dos veces. El desarrollador dijo que era «por diseño», ya que los resultados tenían puntuaciones de relevancia idénticas y la base de datos no garantizaba un orden definido en empates. Yo argumenté que era un bug de UX aunque técnicamente fuera correcto: los usuarios esperan resultados consistentes. Mostré grabaciones de sesiones de usuario donde se evidenciaba la confusión al ver los resultados cambiar entre búsquedas. Llegamos a un acuerdo: añadimos una ordenación secundaria por fecha de creación para resultados de igual relevancia, obteniendo un orden determinista sin alterar el algoritmo de relevancia. Aprendí que los debates sobre «bug o característica» se resuelven mejor analizando el impacto en el usuario, no la corrección técnica. Si los usuarios se confunden, hay que cambiar algo independientemente de lo que diga la especificación.

Respuesta modelo

Cuando me uní al equipo, los desarrolladores escribían pruebas unitarias mínimas y dependían por completo de QA para detectar bugs. En lugar de dar lecciones sobre cobertura de pruebas, empecé a programar en pareja el código de pruebas con los desarrolladores durante las revisiones de código. Les decía: «Así probaría yo esta función. ¿Añadimos estos casos?» Tras unas pocas sesiones, los desarrolladores empezaron a escribir sus propias pruebas. También creé un «muro de bugs»: un panel que mostraba dónde se encontraban los errores (prueba unitaria, prueba de integración, QA o producción). En 3 meses, los datos demostraron claramente que los bugs detectados más tarde costaban exponencialmente más en corrección. El número de bugs en producción bajó un 55% a medida que los desarrolladores interiorizaron la mentalidad de desplazar las pruebas hacia la izquierda. La clave fue hacerlo de forma colaborativa: me posicioné como facilitador de la calidad, no como policía de bugs.

Respuesta modelo

La pirámide de pruebas tiene tres capas: pruebas unitarias en la base (rápidas, aisladas, en gran cantidad), pruebas de integración en el centro (verifican la interacción entre componentes, en cantidad moderada) y pruebas de extremo a extremo en la cima (lentas, sobre el sistema completo, pocas). En la práctica, apunto a una distribución aproximada de 70% unitarias, 20% de integración y 10% E2E. Las pruebas unitarias cubren funciones individuales y casos límite: se ejecutan en milisegundos y ofrecen retroalimentación inmediata. Las pruebas de integración verifican que los componentes funcionan juntos: que los endpoints de la API devuelven respuestas correctas, que las consultas a la base de datos funcionan contra un esquema real y que los consumidores de mensajes los procesan correctamente. Las pruebas E2E cubren los flujos críticos del usuario: registro, compra, flujo de trabajo principal. Las mantengo al mínimo porque son lentas, inestables y costosas de mantener. El antipatrón que más combato es la «pirámide invertida», donde los equipos tienen 500 pruebas E2E y 20 unitarias. Eso se traduce en ejecuciones de 3 horas, inestabilidad constante y desarrolladores que ignoran los fallos de prueba.

Respuesta modelo

Probaría en cuatro niveles. Pruebas de contrato: validar que los esquemas de solicitud y respuesta coinciden con la especificación OpenAPI. Esto detecta cambios incompatibles antes de que afecten a los consumidores. Pruebas funcionales: para cada endpoint, probar los caminos felices, los errores de validación (campos faltantes, tipos incorrectos, valores límite), la autenticación y autorización (acceso no autorizado, rol incorrecto) y los casos extremos (colecciones vacías, tamaños máximos de payload, caracteres especiales). Pruebas de integración: verificar que la API interactúa correctamente con sus dependencias: operaciones de base de datos, llamadas a servicios externos y publicación en colas de mensajes. Usar una base de datos real con datos de prueba, pero simular los servicios externos a nivel de red. Pruebas de rendimiento: medir el tiempo de respuesta bajo carga normal (línea base), realizar pruebas de estrés para encontrar el punto de ruptura y pruebas de resistencia para detectar fugas de memoria durante periodos prolongados. Automatizaría todo en el pipeline de CI: pruebas de contrato y funcionales en cada PR, pruebas de integración al fusionar con main y pruebas de rendimiento cada noche. Usaría Postman/Newman para las pruebas funcionales, k6 o JMeter para el rendimiento y Pact para las pruebas de contrato.

Respuesta modelo

Un stub devuelve respuestas preconfiguradas: reemplaza una dependencia con una versión simplificada que produce salidas predecibles. Lo uso cuando necesito que una dependencia devuelva datos específicos para mi prueba, pero no me importa cómo se invoque. Un mock es un stub que además registra cómo fue llamado y permite verificar las interacciones: ¿se llamó a este método con estos argumentos? Lo uso cuando el comportamiento que pruebo es la interacción en sí, como verificar que un servicio envía un correo electrónico tras el registro, independientemente del contenido del correo. Un fake es una implementación funcional con atajos: una base de datos en memoria en lugar de PostgreSQL, un sistema de archivos local en lugar de S3. Lo uso cuando necesito un comportamiento realista pero no puedo usar la dependencia real en las pruebas. Mi regla general: prefiero fakes para almacenes de datos (más realistas), stubs para APIs externas (predecibles) y mocks con moderación para verificar interacciones. El exceso de mocks es un antipatrón común: si todo está simulado, estás probando tus mocks, no tu código.

Respuesta modelo

Las pruebas inestables son un problema serio: erosionan la confianza en la suite y acostumbran a los desarrolladores a ignorar los fallos. Mi enfoque tiene cuatro pasos. Primero, identificar las pruebas inestables de forma sistemática: etiqueto las que fallan de manera intermitente y hago seguimiento de su tasa de fallos. Cualquier prueba que falle más de una vez sin un cambio de código se considera inestable. Segundo, poner en cuarentena: mover las pruebas inestables a una suite separada que se ejecuta pero no bloquea los despliegues. Esto preserva la relación señal-ruido de la suite principal. Tercero, corregir las causas raíz; las fuentes más comunes son problemas de sincronización (añadir esperas explícitas para operaciones asíncronas en lugar de sleep), estado compartido (garantizar el aislamiento de pruebas con una configuración y limpieza adecuadas), dependencias externas (simularlas o contenerizarlas) y dependencias de orden (pruebas que pasan individualmente pero fallan cuando se ejecutan tras otra). Cuarto, prevenir nuevas pruebas inestables: añadir detección de reintentos en CI. Si una prueba pasa al reintentarla, marcarla como potencialmente inestable y crear una tarea para investigarla. He comprobado que tratar las pruebas inestables con la misma urgencia que los bugs de producción mantiene la suite fiable.

Respuesta modelo

No argumentaría a favor del «tiempo de pruebas» en abstracto: haría el riesgo concreto. Preguntaría: «¿Cuánto nos cuesta enviar un bug crítico a nuestros 50.000 usuarios?» Luego presentaría un plan de pruebas basado en el riesgo. No puedo probarlo todo, así que identificaría las áreas de mayor riesgo: código nuevo, código modificado y flujos críticos del usuario (pago, autenticación, integridad de datos). Propondría un plan de pruebas específico de 2 días que cubra estas áreas, con pruebas de regresión automatizadas ejecutándose en paralelo. También presentaría la alternativa: podemos lanzar sin pruebas, pero necesitamos un plan de reversión rápida y alguien de guardia para responder a incidencias. Hacer explícito el intercambio («ahorramos 2 días pero aceptamos el riesgo X») suele cambiar la conversación. Si el jefe de producto insiste en cero pruebas, dejaría documentada la decisión y los riesgos por escrito. En mi experiencia, cuando cuantificas el riesgo con claridad, la respuesta casi siempre es «encontremos esos 2 días».

Respuesta modelo

Primero, evalúo la gravedad y el impacto. Si afecta a funcionalidades principales (pérdida de datos, seguridad, pagos), escalo de inmediato y recomiendo retrasar el lanzamiento sin excepciones. Si es un problema de interfaz o afecta a un flujo secundario, determino si podemos lanzar con el problema conocido y aplicar un hotfix en las siguientes 24 horas. Comunico con claridad al responsable del lanzamiento y al propietario del producto: aquí está el bug, este es el impacto, estas son las opciones. Opción A: retrasar el lanzamiento, corregir el bug, ejecutar regresión. Opción B: lanzar sin la funcionalidad afectada (desactivarla con un feature flag). Opción C: lanzar con el problema conocido y aplicar el hotfix al día siguiente. Ofrezco mi recomendación, pero dejo la decisión a quienes tienen la responsabilidad de negocio. Lo que no haría: ignorarlo, minimizarlo o intentar una corrección apresurada sin pruebas. Cada «arreglo rápido» que he visto intentar 1 hora antes de un lanzamiento ha introducido un segundo bug, peor que el primero.

Respuesta modelo

Empezaría probando lo que puedo deducir de la propia funcionalidad: la usaría como lo haría un usuario y documentaría mis suposiciones. Crearía un plan de pruebas basado en esas suposiciones y lo compartiría con el jefe de producto y el desarrollador: «Esto es lo que planeo probar. Estas son las suposiciones que hago. ¿Son correctas? ¿Qué me falta?» Este enfoque es más rápido que esperar unos requisitos perfectos y suele revelar lagunas que el jefe de producto no había contemplado. Para cada laguna, haría preguntas concretas: «¿Qué ocurre si el usuario escribe más de 500 caracteres? ¿Qué debe decir el mensaje de error? ¿Debe el formulario conservar los datos si falla la validación?» También revisaría funcionalidades similares del producto para detectar patrones de consistencia. El objetivo es convertir requisitos vagos en criterios de aceptación verificables mediante conversación, sin esperar una especificación perfecta que quizás nunca llegue.

Respuesta modelo

Lo trataría como una investigación genuina, no como una confrontación. Primero, verificaría la afirmación de la prueba contra los requisitos actuales: ¿está la prueba comprobando un comportamiento obsoleto? Si la funcionalidad cambió intencionadamente y la prueba no se actualizó, hay una brecha en el proceso, no una prueba incorrecta. Actualizaría la prueba para que refleje el nuevo comportamiento. Segundo, comprobaría si el cambio fue intencional revisando el historial de commits, la descripción del pull request y cualquier tarea vinculada. Si hay una decisión documentada de cambiar el comportamiento, la prueba debe actualizarse. Si no hay documentación, consultaría al desarrollador y al jefe de producto para confirmarlo. A veces los desarrolladores cambian el comportamiento sin querer durante una refactorización y la prueba «incorrecta» ha detectado una regresión real. En cualquier caso, la conversación produce un buen resultado: o actualizamos la prueba (y el cambio queda documentado) o descubrimos una regresión no intencionada. También señalaría la mejora de proceso: los cambios de comportamiento deben incluir la actualización de las pruebas en el mismo PR.