Simulación de entrevistas QA: cómo defender una estrategia de pruebas

Simulación de entrevistas QA: cómo defender una estrategia de pruebas

En una entrevista para QA, no siempre se evalúa si puedes enumerar muchos casos de prueba. Con frecuencia, el entrevistador presenta una funcionalidad incompleta, agrega una condición a mitad de la conversación y observa cómo reorganizas tu estrategia.

Por ejemplo: debes probar el checkout de una tienda online, pero luego se aclara que también admite cupones, pagos rechazados y compras desde dispositivos móviles. La dificultad no está solo en encontrar escenarios, sino en hacer preguntas, identificar riesgos, delimitar la cobertura y explicar qué priorizarías.

Este ejercicio muestra cómo razonar ante una simulación de entrevista QA, incluyendo un ejemplo de respuesta y una rúbrica para recibir feedback específico.

Qué se evalúa realmente en una entrevista técnica de QA

Una buena respuesta no consiste en mencionar pruebas unitarias, integración, API y regresión de forma aislada. El entrevistador suele buscar evidencias de que puedes tomar decisiones con información incompleta.

• Comprensión del negocio: qué problema resuelve la funcionalidad y qué impacto tendría un fallo.
• Clarificación de requisitos: qué preguntas haces antes de empezar a probar.
• Identificación de riesgos: qué escenarios pueden provocar pérdida de dinero, datos incorrectos o una mala experiencia.
• Priorización: qué validarías primero si el tiempo fuera limitado.
• Diseño de cobertura: qué pruebas manuales, de API, automatizadas o exploratorias utilizarías.
• Comunicación: cómo explicas lo que cubriste, lo que no cubriste y qué riesgos permanecen.

En este tipo de conversación no existe necesariamente una única respuesta correcta. Dos estrategias pueden ser válidas si están bien justificadas y son coherentes con el contexto.

El caso de entrevista: un checkout que cambia durante la conversación

Supón que el entrevistador plantea este escenario:

“La aplicación permite a una persona comprar productos desde un carrito. Al confirmar la compra, se registra el pedido y se muestra una confirmación.”

Antes de enumerar casos de prueba, conviene aclarar el alcance. Algunas preguntas razonables serían:

• ¿La compra requiere que la persona inicie sesión?
• ¿Qué medios de pago están disponibles?
• ¿El inventario se descuenta al confirmar el pedido o después de aprobar el pago?
• ¿Qué ocurre si el pago es rechazado?
• ¿La confirmación se muestra solo en pantalla o también se envía por correo?
• ¿Se permiten cupones, descuentos o impuestos?
• ¿Qué sucede si la persona hace doble clic en el botón de compra?
• ¿La funcionalidad debe funcionar en móvil y escritorio?
• ¿Qué sistemas externos participan en el flujo?

Estas preguntas no son una demora innecesaria. Ayudan a descubrir reglas de negocio y dependencias que cambian significativamente la estrategia de pruebas.

La funcionalidad cambia: se agrega un cupón de descuento

El entrevistador añade una condición:

“Ahora el checkout también permite introducir un cupón. El descuento se aplica si el cupón es válido y no está vencido.”

En lugar de continuar con la lista inicial como si nada hubiera cambiado, una respuesta sólida reconoce que el nuevo requisito introduce riesgos adicionales:

• El cupón podría aplicarse a productos que no cumplen las condiciones.
• El descuento podría calcularse de forma incorrecta por redondeos o impuestos.
• Un cupón vencido podría seguir siendo aceptado.
• El total mostrado podría no coincidir con el total enviado al backend.
• El cupón podría aplicarse dos veces al actualizar el carrito o repetir la solicitud.
• Una respuesta lenta o fallida del servicio de cupones podría bloquear todo el checkout.

La capacidad de adaptar la estrategia es más importante que haber preparado previamente una lista fija de casos.

Cómo delimitar la cobertura antes de diseñar pruebas

Una estrategia de pruebas debe establecer qué se validará y con qué profundidad. Sin esta delimitación, es fácil prometer una cobertura que no puede completarse o concentrarse en detalles de bajo impacto.

1. Separar el flujo principal de las reglas críticas

Primero identificaría el flujo principal:

1. La persona tiene productos en el carrito.
2. Introduce los datos requeridos.
3. Selecciona un medio de pago.
4. Opcionalmente aplica un cupón válido.
5. Confirma la compra.
6. El sistema procesa la operación y muestra el resultado.

Después separaría las reglas que pueden modificar ese flujo: carrito vacío, producto sin stock, cupón inválido, pago rechazado, sesión expirada, error de un servicio externo y repetición de la solicitud.

2. Priorizar por riesgo

No todos los escenarios tienen el mismo impacto. En un checkout B2C, priorizaría especialmente:

• Que una compra aprobada no genere un pedido.
• Que se genere un pedido sin que el pago haya sido aprobado.
• Que se cobre un importe diferente al mostrado.
• Que el descuento se aplique de manera incorrecta.
• Que una repetición de la solicitud cree pedidos duplicados.
• Que el inventario quede en un estado inconsistente.
• Que los datos de otra persona sean visibles o se mezclen con la compra actual.

Esta priorización combina impacto, probabilidad y dificultad de detección. Un error visual menor puede ser importante, pero normalmente no tiene la misma prioridad que cobrar dos veces una operación.

3. Explicitar los límites

También conviene declarar qué quedaría fuera o tendría una cobertura limitada. Por ejemplo, en una primera ronda podría no cubrir todas las combinaciones de navegador, idioma, moneda y dispositivo. Eso no significa ignorarlas: significa registrar el riesgo y proponer cuándo abordarlas.

Una formulación clara sería: “En el tiempo disponible cubriría primero el flujo crítico en los navegadores y dispositivos definidos por el producto. Dejaría para una segunda etapa la matriz completa de combinaciones y pruebas visuales detalladas, salvo que existan antecedentes de fallos en ese ámbito.”

Qué pruebas manuales y de API propondría

La elección entre pruebas manuales y de API no debería plantearse como una competencia. Cada enfoque permite observar aspectos diferentes del sistema.

Pruebas manuales y exploratorias

Las pruebas manuales son útiles para validar el flujo desde la perspectiva de la persona usuaria y para explorar comportamientos que todavía no están completamente definidos.

• Completar una compra válida con y sin cupón.
• Verificar que los mensajes de error sean comprensibles.
• Confirmar que el total se actualice al agregar o quitar productos.
• Intentar aplicar un cupón vacío, inexistente, vencido o con formato incorrecto.
• Actualizar la página durante el proceso.
• Usar el botón de confirmación varias veces.
• Comprobar el comportamiento en una pantalla pequeña.
• Explorar qué ocurre si una dependencia responde lentamente o deja de estar disponible.

La exploración puede revelar problemas de experiencia, estados no contemplados y contradicciones entre el comportamiento de la interfaz y las reglas del negocio.

Pruebas de API

Si el checkout expone una API, probaría directamente los contratos y las reglas que no deberían depender de la interfaz gráfica:

• Solicitud válida con datos completos.
• Campos obligatorios ausentes o con tipos incorrectos.
• Identificador de cupón inválido o vencido.
• Importes manipulados desde el cliente.
• Solicitud repetida con el mismo identificador de operación, si existe un mecanismo de idempotencia.
• Usuario sin autorización para acceder al carrito o al pedido.
• Respuesta de pago aprobada, rechazada o indeterminada.
• Consistencia entre el importe calculado por el servidor y el mostrado al cliente.

Las pruebas de API permiten validar reglas con mayor rapidez y aislar problemas del frontend. Sin embargo, no sustituyen por completo las pruebas de interfaz: una API puede responder correctamente mientras la pantalla muestra un total antiguo o un mensaje equivocado.

Cómo priorizar la regresión y comunicar los riesgos

Cuando una modificación introduce cupones en el checkout, la regresión no debería limitarse al nuevo campo. Hay que revisar las partes existentes que podrían verse afectadas.

Una regresión prioritaria podría incluir:

• Creación de pedidos sin cupón.
• Creación de pedidos con cupón válido.
• Rechazo de cupones inválidos o vencidos.
• Cálculo del total con diferentes cantidades de productos.
• Pago rechazado y recuperación posterior.
• Actualización del inventario.
• Prevención de pedidos duplicados.
• Visualización de la confirmación y envío de notificaciones, si forman parte del alcance.

La automatización puede ser apropiada para los escenarios repetitivos y críticos, especialmente los que se ejecutan en cada cambio. Las pruebas manuales siguen siendo valiosas para exploración, usabilidad, validaciones visuales y comportamientos nuevos que todavía están evolucionando.

Al comunicar el resultado, evitaría decir simplemente “todo está probado”. Informaría algo como:

“Validé el flujo principal con y sin cupón, los rechazos básicos, los importes calculados por la API y la prevención de una repetición de la solicitud. No cubrí todavía todas las combinaciones de navegador ni escenarios de recuperación ante una caída prolongada del proveedor de pagos. El riesgo principal pendiente está relacionado con esas dependencias y con la matriz de dispositivos.”

Esta forma de comunicar aporta contexto para decidir si el producto puede avanzar y qué riesgos deben aceptarse, mitigarse o investigarse.

Ejemplo de respuesta razonada en una entrevista

Una respuesta completa podría expresarse así:

“Primero aclararía las reglas del checkout: medios de pago, autenticación, momento en que se descuenta el inventario, comportamiento ante pagos rechazados y condiciones de los cupones. Después priorizaría los riesgos económicos y de consistencia: cobrar un importe incorrecto, crear pedidos duplicados, crear un pedido sin pago aprobado o aplicar un cupón cuando no corresponde.

Comenzaría con pruebas del flujo feliz y de los rechazos principales. En la interfaz validaría el recorrido, los mensajes, la actualización del total y el comportamiento ante doble clic o recarga. En la API probaría validaciones, autorización, cálculo del importe, cupones inválidos y repetición de solicitudes. También comprobaría que el cliente no pueda modificar el precio final enviando otro importe.

Para la regresión repetiría las compras sin cupón, con cupón, con pago rechazado y con diferentes estados del carrito. Automatizaría los escenarios estables y críticos, pero mantendría pruebas manuales exploratorias para el nuevo comportamiento y para la experiencia de uso. Si el tiempo fuera limitado, dejaría fuera la matriz completa de dispositivos y algunas combinaciones poco frecuentes, documentando ese riesgo en lugar de presentarlo como cobertura completa.”

Esta respuesta no pretende cubrir todos los casos posibles. Su valor está en mostrar una secuencia de razonamiento: entender, priorizar, elegir técnicas y comunicar límites.

Rúbrica para evaluar y mejorar tu respuesta

Puedes utilizar la siguiente rúbrica para practicar con otra persona o revisar una grabación de tu simulación:

• Clarificación de requisitos: ¿hiciste preguntas sobre reglas, dependencias y criterios de aceptación?
• Riesgos: ¿identificaste consecuencias relevantes para el negocio y las personas usuarias?
• Priorización: ¿explicaste qué probarías primero y por qué?
• Cobertura: ¿diferenciaste flujo principal, errores, límites, regresión y exploración?
• Elección de técnicas: ¿justificaste cuándo usar pruebas manuales, de API o automatizadas?
• Adaptabilidad: ¿reorganizaste la estrategia cuando apareció el requisito del cupón?
• Comunicación: ¿explicaste qué quedaba fuera sin afirmar que todo estaba cubierto?
• Razonamiento: ¿defendiste tus decisiones con impacto y riesgo, en lugar de enumerar casos sin contexto?

El feedback más útil debe ser específico. En vez de decir “te faltaron casos”, conviene preguntar: “¿Qué riesgo no mencionaste?”, “¿por qué priorizaste esa prueba?”, “¿qué información necesitabas antes de decidir?” o “¿cómo comunicarías este riesgo al equipo?”

Conclusión: defender una estrategia es explicar decisiones

En una entrevista QA, una estrategia sólida no se mide por la cantidad de casos que puedes recitar. Se demuestra al convertir una funcionalidad ambigua en un plan razonado: aclarar requisitos, identificar riesgos, priorizar la cobertura, combinar pruebas manuales y de API, revisar la regresión y comunicar las limitaciones.

Practica explicar tus decisiones con un caso realista y acostúmbrate a adaptar la respuesta cuando cambian los requisitos. Si necesitas feedback individual para preparar entrevistas QA, conoce la simulación de entrevistas técnicas de Mentores Tech.