¿Como escribir un buen reporte de Fallas/Bugs?

El punto de escribir un reporte de bug es que el bug sea corregido.

By Cem Kaner.

¿Por que es necesario escribir un buen reporte de bugs?
Si el bug/falla se reporta eficientemente las probabilidades de que sea solucionado rápidamente serán mayores. Entonces la solución de una falla dependerá de la eficiencia con que se reporte la misma.
Si vamos a un ejemplo, comúnmente vemos que si una falla no se reporta bien, el desarrollador va a devolver la misma como no reproducible (ya que la información provista no le permite generar la falla en sus ambientes). Esto puede generar que se aumente la carga de trabajo para el tester (el bug vuelve a sus manos y tiene que revisar si la falla que pasó ocurre realmente) y que el tester sienta herido su orgullo ya que según el desarrollador, el tester pasó una falla que no es tal. Esto puede llegar a generar un mal ambiente de trabajo y se puede perder el objetivo de las tareas de cada uno, que es indicar la falla por un lado y solucionarla por el otro (para poder entregar a tiempo y con calidad), volviéndose un tema de idas y vueltas (y de búsqueda de culpables) que se podría haber evitado con un correcto reporte del bug.
¿Cuales son los problemas más comunes con los reportes de fallas?
Creo que determinados problemas se dan se dan más allá del rol de la persona que reporta la falla y otros problemas se dan más que nada por cuestiones de roles, por experiencia o directamente por que la empresa en la que se desarrolla la actividad no tiene bien definido el proceso.
Los problemas más frecuentes suelen ser:

• Redactar la falla de manera excesivamente coloquial y ambigua (esto puede ser grave más que nada cuando el que reporta es un tester, no tanto en el caso de un usuario final al que hay que interrogar un poco más)
• Dar solo una captura de la falla sin indicar que se estaba haciendo cuando sucedió el bug (suele suceder cuando reportan fallas los analistas o los usuarios finales).
• No incluir en la descripción de la falla cual era el resultado esperado para los pasos realizados.
• No determinar un patrón con el cual el incidente ocurre antes de reportar el mismo. Esto me parece muy importante para ser directos en cual es el problema y para que desarrollo lo pueda reproducir.
• No leer el incidente reportado siguiendo los pasos uno mismo para ver que la descripción es clara para el que lo lee.
• No incluir información que dada las características del bug, la misma es de relevancia. Por ejemplo indicar solo que se ingresaron datos inválidos, pero no incluir cual fue el dato en cuestión.

¿Cuales son las causas más comunes por lo que se da esto?
Por lo que pude recabar en la consulta realizada en el grupo de Testing en Linked In, las causas más importantes que provocan estos problemas son:

1. Falta capacitación.
2. Falta de tiempo (a menor capacitación mucha mayor necesidad de tiempo para determinar y definir el problema)
3. Falta de reglas claras dentro de la organización/proyecto.
4. Falta de generarse una rutina propia que se adapte a nuestras skills y nos genere una disciplina que nos sea cómoda y útil para los demás que leen la falla.

¿Cuales son los lineamientos básicos a seguir para reportar un bug eficientemente?
Los puntos básicos que tiene que tener un bug son:

• Reporter: Tester que lo reportó. Esto facilitará la comunicación entre el que lo reportó y el que lo va a solucionar.
• Versión: Indica la versión de la aplicación en que se detectó la falla.
• Ambiente: Indica sobre que ambiente de pruebas ocurrió la falla.
• Componente: Indica sobre que componente/módulo/submódulo/pantalla se detectó la falla.
• Plataforma y Sistema Operativo: Indica sobre las características de hard y sistema operativo de la maquina en donde se detectó la falla.
• Navegador: Indica el navegador que se estaba utilizando cuando se detectó la falla.
• Prioridad: Se indica “cuando” debe arreglarse la falla. Este parámetro nos ayuda a indicarle al desarrollador con que urgencia necesitamos la corrección del bug.
• Severidad: Indica el impacto de la falla sobre la aplicación.
• Resumen: Descripción corta que describe la falla en forma simple y concreta.
• Descripción: Detalle de los pasos realizados para poder reproducir la falla, junto con los datos utilizados y la generación del escenario para que ocurra el bug.
• Falla: Descripción que indica cual es el error exactamente.
• Esperado: Descripción de que debería ocurrir en lugar de la falla.
• Adjuntos: Cualquier material complementario que sirva para ayudar al desarrollador a solucionar la falla (screenshots, logs, documentos, etc…)
• Estado: En que situación se encuentra la falla para indicar si ya puede ser tomada por el desarrollador, si ya fue solucionada o si todavía no puede revisarla.

¿Que consideraciones debo tener al momento de reportar el bug/falla?
Al momento de reportar un bug/falla debemos tener en cuenta las siguientes consideraciones:

• Los bugs deben tener identificadores únicos
  Si bien muchas herramientas de bugtracking asignan automáticamente un ID único a los bugs, muchas veces se reportan fallas por medio de mails, saltando la registración en la herramienta y dejando el bug perdido en el limbo hacia donde será muy difícil hacer referencia o realizar un seguimiento. Entonces, siempre hay que registrar los bugs con un ID único (ya sea mediante una herramienta para bugtracking o solo una planilla en txt o excel)
• Una falla debe ser reproducible para reportarla
  Si el bug no es reproducible, no es un bug. Para fallas que ocurren en forma aislada, podemos realizarnos una nota personal para investigar luego y determinar que condiciones deben ser dadas para que el mismo se produzca, pero reportar una falla que nosotros mismos no podemos reproducir no es muy productivo ya que solo cargaremos la herramienta de bugs con fallas que serán devueltas como no reproducibles, ese será su único destino, generando una perdida de tiempo por parte del tester en reportarlo y por parte del desarrollador en revisarlo y probar variantes para reproducirlo.
• Debe reportarse cada paso realizado para reproducirlo
  Toda la información que podamos darle al desarrollador para que pueda reproducir la falla siempre será bienvenida, no debemos obviar ningún paso que sea relevante para llegar al error en cuestión. Una buena practica es reproducir el error una o más veces siguiendo solo los pasos que escribimos, como si no lo conociéramos, esto nos ayudara a detectar información de más (o faltante) y si la falla es reproducible con la información que se detalla.
• Ser especifico
  No se debe escribir suposiciones o ideas sobre lo que esta ocurriendo u otra cosa que no sea la información relevante para poder reproducir el bug.
• Describir el bug de forma simple y corta en el resumen del mismo
  Es importante que el desarrollador puede hacerse una idea del bug con solo leer el summary/resumen del mismo, para que al entrar a leer la descripción del mismo ya tenga una idea de hacia adonde apunta el camino.
• Investigar el patrón con el que ocurre el bug
  Hay que tener en cuenta que los bugs siguen siempre un determinado patrón para ocurrir, ya que los mismos son fallas en el código. Debemos esforzarnos para encontrar el patrón que hace que se pase siempre por la sección de código donde esta la falla.

http://josepablosarco.wordpress.com/2010/12/09/%C2%BFcomo-escribir-un-buen-reporte-de-fallasbugs/