Una entrevista de QA Manual verifica tu dominio de la teoría de testing, técnicas de diseño de pruebas, y tu capacidad de escribir reportes de bugs sobre los que un desarrollador realmente pueda actuar. Aquí están las preguntas hechas más a menudo a nivel Junior y Middle, cada una con una respuesta modelo. Middle: comprensión más profunda, optimización y situaciones reales de trabajo.
Seleccionas por riesgo, no por cobertura. Eso significa qué cambió en este release y qué lo toca, los flujos que pierden dinero si se rompen — auth, checkout, pago — y las áreas con más historial de defectos. Luego dices en voz alta qué no corriste, así la decisión de lanzar es del equipo y no silenciosamente tuya.
No lo decides solo, pero lo enmarcas: cuántos usuarios lo golpean, con qué frecuencia, hay un workaround, qué riesgo tiene el fix de romper algo. Un desalineamiento cosmético en una pantalla raramente usada con un release mañana es un "ahora no" legítimo. Lo que no es legítimo es cerrarlo calladamente — va al backlog con el razonamiento, si no el mismo bug se vuelve a encontrar cada trimestre.
Empieza asumiendo que los entornos difieren, no que el test está mal. Compara datos, configuración, feature flags, versiones, y timing — staging usualmente es más lento, lo que expone race conditions y esperas implícitas. Luego revisa si el test depende de estado que dejó otro test. Declararlo flaky y volver a correrlo es lo que convierte un bug de entorno real en un rojo permanentemente ignorado.
Códigos de status tanto para éxito como para fallo, el schema y tipos de la respuesta, campos requeridos versus opcionales, y qué pasa con campos faltantes, extra, o de tipo equivocado. Luego autorización — el mismo request sin un token y con el token de alguien más. Finalmente los bordes: arrays vacíos, payloads enormes, y llamadas repetidas, ya que la idempotencia es donde se esconden los bugs de API.
No esperas requisitos perfectos, haces visible la ambigüedad. Escribe cómo la interpretaste, lista los casos que la spec no responde, y llévalos al analista o product owner antes de construir casos sobre una suposición. Preguntas hechas antes de que termine el desarrollo cuestan una conversación; las mismas preguntas hechas después cuestan un rework.
Dice que la mayoría de las verificaciones deberían ser unit tests rápidos, menos integration tests, y muy pocos end-to-end lentos. Para QA manual la consecuencia es que tu tiempo se desperdicia re-corriendo cosas que un unit test ya cubre. El esfuerzo manual pertenece donde los humanos son mejores que las máquinas: exploratory testing, usabilidad, y escenarios que a nadie se le ocurrió automatizar.
Un bug es un comportamiento que contradice un requisito, una especificación, o una expectativa razonable del usuario. Un feature request pide un comportamiento que nunca se acordó. La zona gris es el tercer caso — la spec calla y el comportamiento es malo — y discutir sobre la etiqueta ahí desperdicia tiempo. Describe el impacto, deja que el product owner decida la etiqueta, y asegúrate de que no se pierda de ninguna forma.
En una entrevista real hablas bajo presión. Cam hace estas mismas preguntas, evalúa cada respuesta y muestra exactamente qué mejorar.
Practicar entrevista de Middle Manual QA →