Senior Manual QA — Preguntas de entrevista QA Manual

Te unes a un equipo sin ningún proceso de testing. ¿Qué haces en el primer mes?

Primero averigua dónde duele realmente la calidad: habla con soporte, lee los últimos tres meses de incidentes, pregunta a los desarrolladores qué les da miedo tocar. Luego arregla lo más barato con el mayor efecto, usualmente una suite de smoke en el camino crítico más un flujo de bugs que la gente siga. Escribir un documento de estrategia de testing en la primera semana es el error clásico — nadie lo lee, y todavía no te has ganado la credibilidad para eso.

¿Cómo justificas el headcount de QA a un manager que ve el testing como un costo?

Dejas de discutir sobre cobertura y empiezas a mostrar qué se escapó. Rastrea los defectos encontrados después del release, qué cuestan en tiempo de soporte, hotfixes, y clientes perdidos, y compara con lo que cuesta atraparlos antes. El argumento que gana no es "necesitamos más testers", es "esto es lo que nos costó lanzar roto el trimestre pasado, y esto es lo que gastaríamos para prevenir la mayor parte".

¿Qué te haría argumentar en contra de automatizar un test?

Cuando la feature todavía está cambiando, porque mantendrías el test más de lo que te protege. Cuando la verificación es barata para un humano y cara para una máquina, como el juicio visual o la usabilidad. Cuando el test es inherentemente flaky — timing, terceros, pagos reales — ya que un build rojo en el que nadie confía es peor que ningún build. La automatización rinde en caminos estables, repetitivos, de alto valor, no en todo.

Un bug crítico llegó a producción. ¿Cómo corres el follow-up?

Sin culpa, y sobre el mecanismo en vez de la persona. Establece la línea de tiempo, separa el disparador de la razón por la que pasó, y pregunta por qué cada capa lo dejó pasar — requisitos, review, tests, entorno. El resultado es un pequeño número de cambios con dueño, no una resolución de "ser más cuidadosos". Si la misma clase de bug se escapó dos veces, el proceso es el defecto, no el tester.

¿Cómo decides qué métricas de calidad reportar, y cuáles mienten?

Las métricas útiles responden una pregunta sobre la que alguien actuará: defectos escapados, tiempo para detectar, tasa de flakiness, cobertura de flujos críticos. El número de test cases y el número de bugs encontrados son las clásicas engañosas, porque ambas premian escribir más de algo en vez de encontrar lo que importa — y ambas suben cuando la calidad empeora. Cualquier métrica que reportes se va a optimizar, así que reporta solo las que estarías feliz de ver manipuladas.

Producto quiere cortar QA del sprint para cumplir una fecha. ¿Cómo respondes?

No con un rechazo, con un trade. Nombra específicamente qué no se va a verificar y qué podría llegar a los usuarios como resultado, en sus términos — ingresos, carga de soporte, reputación. Ofrece un alcance más pequeño que genuinamente puedas cubrir en vez de pretender que el completo cabe. El objetivo es que la decisión se tome con el riesgo visible; si igual lanzan, esa es una decisión de negocio legítima y ahora está documentada.