Un buen reporte permite que otra persona reproduzca el problema sin preguntarte nada: un título específico, pasos exactos desde un estado inicial conocido, resultado esperado frente a resultado real, entorno y build, y evidencia como un vídeo, logs o una traza de red. La severidad es el impacto técnico del defecto; la prioridad es lo pronto que se arregla. Un bug estético puede ser de severidad baja y prioridad alta.
Por qué lo preguntan los entrevistadores
Los reportes de bugs son la principal salida escrita de alguien de test, así que esto es una comprobación directa de oficio. Los entrevistadores quieren el foco en la reproducción y la evidencia, y quieren específicamente la distinción entre severidad y prioridad con un ejemplo donde diverjan, porque quien las mezcla tiende a discutir el triaje con producto en vez de describir el impacto y dejar que el negocio priorice.
Cómo estructurar tu respuesta
- Enuncia el objetivo: reproducible sin necesidad de conversación.
- Enumera los elementos obligatorios en orden.
- Define severidad y prioridad por separado.
- Da un ejemplo donde divergen en cada dirección.
- Señala que tú describes el impacto y el negocio fija la prioridad.
Ejemplo de respuesta
Mi prueba para un reporte de bug es si un desarrollador que nunca ha hablado conmigo puede reproducirlo solo con el reporte. Así que el título dice qué se rompe y dónde, de forma específica, no algo como la compra está rota. Después las precondiciones, o sea el estado inicial exacto y el tipo de cuenta, pasos numerados que alguien pueda seguir al pie de la letra, resultado esperado, resultado real, y el entorno y número de build, porque un bug reportado contra el build de la semana pasada le arruina la tarde a todo el mundo. La evidencia va siempre: grabación de pantalla, la petición y la respuesta de red, y las líneas de log relevantes con marcas de tiempo. Sobre severidad frente a prioridad, la severidad es cómo de roto está el sistema y la prioridad es cuándo lo arreglamos, y las fijan personas distintas por motivos distintos. Un bug de corrupción de datos en una funcionalidad que usan dos personas es de severidad alta y prioridad baja. Una errata con el nombre de la empresa mal escrito en la página de inicio es de severidad trivial y se arregla esta mañana. Me aseguro de describir el impacto con precisión, cuántos usuarios, si hay una solución temporal, si hay dinero o datos en riesgo, y luego dejo que la persona de producto fije la prioridad, porque esa decisión es suya.
¿Tienes esta entrevista a la vuelta de la esquina? GhostPilot escucha tu llamada en vivo, detecta la pregunta en cuanto la hacen y pone una respuesta estructurada en tu pantalla en tiempo real. Pruébalo en tu próxima entrevista de práctica, o coge un Session Pass de $29, sin suscripción, para la de verdad.
Mira cómo funcionaPreguntas de seguimiento que puedes esperar
- ¿Cómo escribirías el título de un bug que todavía no puedes reproducir de forma fiable?
- ¿Qué harías si un bug de severidad alta se despriorizara una y otra vez?
- ¿Cuánta investigación debería hacer alguien de test antes de reportar?
Más preguntas para Ingeniero de QA
Tu entrevistador hará su propia versión de esta. Pega la descripción real del puesto en el Question Predictor gratuito y obtén las 20 preguntas que ese puesto tiene más probabilidades de hacerte, con lo que cada una busca en realidad.
Predecir mis preguntas