¿Qué hace que un reporte de bug sea de alta calidad?

Respuesta directa

Qué debe cubrir una buena respuesta

Cómo funciona

Un buen reporte permite que alguien que nunca ha visto el bug lo reproduzca en minutos y juzgue su importancia sin hacer preguntas. El título indica el síntoma y la condición. La sección de entorno da número de build, plataforma, navegador o dispositivo y tipo de cuenta. Los pasos son mínimos y numerados, parten de un estado conocido y usan los datos exactos. El comportamiento esperado y el real van en frases separadas. Frecuencia e impacto dicen con qué frecuencia ocurre y a quién afecta. La evidencia incluye logs, captura o grabación, IDs de solicitud y errores de consola. El diagnóstico se ofrece solo con evidencia y claramente marcado como hipótesis.

Ejemplo

Título: El checkout devuelve 500 cuando la dirección de envío contiene un apóstrofo. Entorno: build web 4.12.3, Chrome 128, cuenta estándar. Pasos: añadir cualquier artículo, ir al checkout, introducir la dirección O’Connor Street, enviar. Esperado: confirmación del pedido. Real: página de error, ID de solicitud 7f3a-… en el pie. Frecuencia: siempre; afecta a cualquier cliente con apóstrofo en la dirección, alrededor del 2 por ciento según el conjunto de direcciones. Evidencia: fichero HAR y extracto del log del servidor adjuntos. Hipótesis: comilla sin escapar en una consulta, según la línea del log.

Errores frecuentes

• Escribir no funciona como descripción.
• Listar veinte pasos que incluyen navegación sin relación.
• Afirmar la causa raíz sin evidencia y enviar a los desarrolladores por el camino equivocado.

Una estructura útil para responder

Responde desde tu propia experiencia.

No memorices un guion: usa solo ejemplos que puedas explicar con honestidad en preguntas posteriores.