Escribiendo Reportes De Error Efectivos

Escribiendo reportes de error efectivos
Le ha pasado alguna vez que le devolvieran un bug pidiendo más información?
Ha encontrado un bug crítico sólo para que fuera aplazado para otra liberación?
Todo reporte de incidente es una comunicación escrita al equipo del proyecto sobre la calidad del
software bajo prueba. Frecuentemente, tu habilidad para comunicar los incidentes de una aplicación – y
nola severidad inherentes a los bugs – determinan que los incidentes sean corregidos o no.
Si este pensamiento les da miedo, ustedes pueden estar pensando:
“Pero, esperen, yo odio escribir y no soy bueno para eso! ¿Cómo puede depender el destino del
incidente del texto del reporte?
Es tentador pensar que los bugs hablan por sí mismos –que cualquier persona en su sano juicio puede
automáticamentever que cierto error es horrible y debería ser corregido. Pero lamentablemente, no es
lo que sucede.
Pero la buena noticia es que su habilidad para comunicase efectivamente con los desarrolladores de
software y el equipo del proyecto, no está predeterminada por cómo les ha ido en la clase de inglés (o
de español) del liceo.
No se trata de escribir una prosa fluida con palabras interesantes. Nisiquiera se trata de gramática y
ortogrfía correcta. Se trata de expresarse claramente, utilizando las palabras estrictamente necesarias
para explicarse. Demasiadas palabras y la idea se pierde entre las ramas. Muy pocas palabras y los
demás llenan los espacios con sus propias suposiciones- con frecuencia en detrimento del software.
Se trata nada más que de saber exactamente qué es lo que hay quecomunicar. Si no están seguros de la
naturaleza del bug, entonces no importa cuán bien puedan escribir el reporte de error, igual nadie más
sabrá tampoco de qué incidente se trata.
Este reporte de incidentes presenta cuatro cosas que ustedes pueden comenzar a hacer desde ya para
aumentar las chances de que las personas presten atención a los errores que reportan.

1: Conozcan a su audiencia
Encualquier curso de escritura les dirán que deben conocer para quién están escribiendo. Los reporetes
de error no son una excepción. Hay al menos dos audiencias para cualquier reporte de error: la persona
que tiene que corregir el error y la persona o grupo que decide el destino del bug. Algunas veces una
sóla persona es responsable por ambas tareas, si embargo las dos audiencias siguen existiendo; sóloque
coinciden en un mismo cuerpo.
La primera audiencia – la persona que debe corregir el error – precisa pasos claros e inequívocos para
reproducir los síntomas. Cuanta más información mejor. Para el propósito de es reporte de error, la
llamaremos “Desarrollador”. El Desarrollador necesita detalles precisos sobre lo que hicieron y vieron.
La segunda audiencia – la persona o grupo que decide sobre eldestino del bug – precisa entender las
consecuencias de elegir no corregir un error. Esta audiencia necesita una declaración concisa para
captar su atención y una discusión sobre las implicancias del bug. Para el propósito de este reporte de
error, llamaremos a esta audiencia “Comité de Revisión de Errores”. Para lograr que los errores se
corrijan, su rol es ayudar al comité a ver que los riesgosde no corregir el error, exceden ampliamente los

posibles riesgos de corregirlo. Cuanto más comprendan cómo trabajan sus Desarrolladores y el Comité,
mejor pueden adecuar los reportes de error a sus necesidades. Hagan el esfuerzo de conocer
personalmente a sus interlocutores. Si pueden participar de las reuniones del Comité de Revisión de
Bugs, háganlo. Aprenderán mucho sobre cómo piensan losdestinatarios de los reportes de error.

2: Elijan un buen título
La breve frase que describe el bug es generalmente denominada, el título o la descripción del error.
Es la parte más importante del reporte de error. Los miembros del Comité de Revisión de Errores, a
menudo deciden que un incidente puede aplazarse basándose solamente en el título; si éste es débil, los
miembros podrían determinar...