Preguntas de entrevista QA Manual

¿Cuál es la diferencia entre verification y validation?

Verification pregunta "¿estamos construyendo el producto correctamente?" — verifica el trabajo contra especificaciones y documentos de diseño, usualmente a través de reviews y análisis estático. Validation pregunta "¿estamos construyendo el producto correcto?" — verifica que el software terminado realmente resuelva el problema del usuario, a través de testing dinámico. Verification pasa durante todo el desarrollo; validation pasa contra requisitos y usuarios reales.

¿Qué es Equivalence Partitioning? Aplícalo a un campo "edad" que acepta 1–120.

Equivalence Partitioning divide los datos de entrada en grupos donde se espera que cada valor se comporte igual, así que testear un valor por grupo es suficiente. Para un campo de edad de 1–120 las particiones son: válido 1–120, inválido por debajo (0 y negativos), inválido por arriba (121+), e tipos inválidos (letras, símbolos, vacío). Eso da cuatro tests en vez de 120.

¿Qué es Boundary Value Analysis? Da un ejemplo para un campo 1–100.

Boundary Value Analysis apunta a los bordes de cada partición, porque ahí es donde se agrupan los errores off-by-one. Para un campo 1–100 testeas 0, 1, 2 en el borde inferior y 99, 100, 101 en el borde superior. Casi siempre se usa junto con Equivalence Partitioning: las particiones te dicen qué grupos existen, los bordes te dicen dónde se rompen.

¿En qué se diferencia Severity de Priority? Da un ejemplo de Severity alta con Priority baja.

Severity describe el impacto técnico del defecto en el sistema; Priority describe cuán urgente el negocio quiere que se arregle. Las fija gente distinta — Severity usualmente el tester, Priority el product owner o manager. Un crash en una pantalla de exportación de admin raramente usada es Severity alta pero Priority baja; un typo en el nombre de la empresa en la landing page es Severity baja pero Priority alta.

Describe el Bug Life Cycle. ¿Qué estados puede tener un bug?

Un defecto típicamente se mueve New → Assigned → Open (en progreso) → Fixed → Retest → Closed. Resultados alternativos son Rejected (no es un defecto), Duplicate, Deferred (pospuesto a un release posterior), y Reopened cuando un retest muestra que el fix no funcionó. Los estados exactos varían por equipo, pero lo importante es que cada bug termina en un estado terminal con una razón documentada.

¿Qué son smoke, sanity, y regression testing? ¿Cuál es la diferencia?

Smoke testing es una verificación superficial y amplia de que el build está lo suficientemente estable como para testear siquiera — si el login está roto, el testing se detiene. Sanity testing es estrecho y profundo: después de un fix específico, verifica que un área funciona como se espera. Regression testing es amplio y repetido: confirma que cambios nuevos no rompieron funcionalidad que antes funcionaba, y es el principal candidato a automatización.

¿Qué es exploratory testing y en qué se diferencia de ad-hoc testing?

Exploratory testing significa diseñar y correr pruebas al mismo tiempo — el tester aprende el producto y usa lo que encuentra para decidir qué probar después. Es estructurado: hay un charter, un time box, y notas. Ad-hoc testing es no estructurado y no documentado, guiado puramente por intuición. Exploratory testing es repetible y reportable; ad-hoc no.

Lista los campos obligatorios de un reporte de bug. ¿Por qué importan los pasos para reproducir?

Un reporte de bug usable tiene un resumen claro, entorno (build, SO, navegador, dispositivo), precondiciones, pasos para reproducir, resultado real, resultado esperado, severity, priority, y adjuntos como screenshots o logs. Los pasos para reproducir importan más porque un defecto que un desarrollador no puede reproducir usualmente se cierra como "no se puede reproducir" — el reporte pierde todo su valor.

¿Qué es un test plan y qué secciones contiene?

Un test plan describe cómo se llevará a cabo el testing para un proyecto o release. Las secciones típicas son alcance (qué se testea y qué no), enfoque y niveles de testing, criterios de entrada y salida, entornos y datos de prueba, roles y responsabilidades, cronograma, riesgos con mitigación, y entregables. Es un documento de gestión — el objetivo es que cualquiera pueda ver qué se testeará, por quién, y cuándo se considera terminado el testing.

¿Cómo testearías un formulario de login? Lista casos positivos y negativos.

Positivos: credenciales válidas inician sesión y redirigen correctamente, "recordarme" persiste la sesión, el reset de contraseña funciona de punta a punta. Negativos: contraseña incorrecta, usuario inexistente, campos vacíos, payloads de SQL injection y XSS, espacios al inicio y al final, sensibilidad a mayúsculas, input extremadamente largo, bloqueo de cuenta tras fallos repetidos. También revisa aspectos no funcionales: la contraseña está enmascarada, el formulario funciona en móvil, las credenciales se envían por HTTPS, y los mensajes de error no revelan si el username existe.

¿Cuáles son los siete principios de testing de ISTQB?

El testing muestra la presencia de defectos pero no puede probar su ausencia; el testing exhaustivo es imposible; el testing temprano ahorra tiempo y dinero; los defectos se agrupan en un pequeño número de módulos; la paradoja del pesticida significa que los tests repetidos dejan de encontrar bugs nuevos; el testing depende del contexto; y la ausencia de errores es una falacia — software sin defectos conocidos igual puede ser inusable si resuelve el problema equivocado.

¿Qué es una Decision Table y cuándo la usas?

Una Decision Table mapea combinaciones de condiciones de entrada a las acciones esperadas del sistema. La usas cuando el comportamiento depende de varias condiciones interactuando — por ejemplo un descuento que depende del tipo de cliente, tamaño de orden, y código promo. Hace obvias las combinaciones faltantes y se convierte directamente en casos de prueba, por eso es la técnica estándar para reglas de negocio complejas.

¿Cuál es la diferencia entre un test case y un checklist? ¿Cuándo usas cada uno?

Un test case describe pasos precisos, datos de prueba, y un resultado esperado — es repetible por cualquiera y conviene para funcionalidad regulada o compleja. Un checklist es una lista de cosas a verificar sin pasos prescritos, confiando en el juicio del tester. Los checklists son más rápidos de escribir y mantener y encajan en trabajo exploratorio o áreas estables y bien entendidas; los test cases encajan en onboarding, auditorías, y features donde el flujo exacto importa.

¿Cuál es la diferencia entre functional y non-functional testing?

Functional testing verifica qué hace el sistema — que las features se comporten según los requisitos. Non-functional testing verifica qué tan bien lo hace: performance, carga, seguridad, usabilidad, accesibilidad, compatibilidad, y confiabilidad. Los defectos non-functional a menudo son más caros de arreglar porque tienden a estar arraigados en la arquitectura en vez de en una sola línea de código.