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. Junior: teoría básica, definiciones y casos prácticos simples.
Verification pregunta si construimos el producto correctamente — coincide con la especificación, el diseño, los requisitos acordados. Validation pregunta si construimos el producto correcto — si realmente resuelve el problema del usuario. Una feature puede pasar verification completamente y aun así fallar validation, que es cómo los equipos lanzan algo que coincide con la spec y nadie quiere.
Divides el input en clases donde cada valor debería comportarse igual, luego testeas un valor de cada una en vez de todos. Aquí eso da tres particiones: menos de 18, de 18 a 65, y más de 65, más las clases inválidas — letras, vacío, negativo. El punto es cobertura sin redundancia: si 30 pasa, 31 no te dice nada nuevo.
Los bugs se agrupan en los bordes de un rango, porque ahí es donde viven los errores off-by-one y los operadores de comparación equivocados. Para un campo que acepta de 18 a 65 testeas 17, 18, 19 y 64, 65, 66. Partitioning te dice qué rangos existen; boundary analysis te dice dónde adentro de ellos están realmente los defectos.
Un reporte usable tiene un título que dice qué está roto, pasos de reproducción exactos, resultado esperado versus real, entorno, y evidencia — un screenshot, video, o log. Lo que hace inútil a un reporte es una precondición faltante o un paso que el reportero hizo sin notarlo, porque el desarrollador no puede reproducirlo y lo cierra como "funciona en mi máquina".
Severity es impacto técnico, priority es cuán pronto debería arreglarse, y las fija gente distinta — severity el tester, priority el product owner. Un typo en el nombre de la empresa en la landing page es severity baja y priority máxima. Un crash en una pantalla de admin usada dos veces al año es severity alta y priority baja.
No, y este es uno de los siete principios ISTQB. El testing puede mostrar que hay defectos presentes; nunca puede mostrar que no queda ninguno, porque el testing exhaustivo de cada input y camino es imposible para cualquier sistema real. Lo que el testing te da es evidencia para decidir si el riesgo es aceptable — no una garantía.
Un test case detalla precondiciones, pasos, y resultado esperado, así que cualquiera puede correrlo de forma idéntica. Un checklist solo nombra qué cubrir y deja el cómo al tester. Los test cases valen su costo para flujos regulados o de alto riesgo y para gente nueva en el producto; los checklists ganan para trabajo exploratorio y para un equipo que conoce el sistema, donde los casos completos se vuelven documentación que nadie actualiza.
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 Junior Manual QA →