El primer paso para que un bug sea resuelto es escribir la incidencia del error. Reportar de forma eficiente un bug encontrado aumenta las posibilidades de que sea resuelto de la forma más rápida y mejor posible.
Los programadores son reacios a ponerse a solucionar bugs con descripciones vagas del error que no indican claramente cómo reproducirlos. Eso es un sobre esfuerzo que hay que sumar al de encontrar el foco del problema en el código. Si no se indica como reproducir el bug difícilmente se podrá debuggear la aplicación.
Cualquier usuario de una aplicación es capaz de detectar un error, o mejor dicho, sufrir un error. Pero pocos serán los que sabrán explicar detalladamente qué estaban haciendo o como llegar a ese punto.
¿Cómo reportar correctamente un bug?
A continuación reflexionamos sobre una serie de puntos importantes para escribir buenos informes de bugs:
-
Asigna siempre un número único identificativo para poder hacer un seguimiento claro de la resolución del bug. Prácticamentee todas las herramientas de gestión de tareas e incidencias en proyectos proveen de un sistema de tickets que identifican de forma inequívoca el error: JIRA, Trac, bugzilla, etc... Apunta ese identificador y usalo cada vez que te refieras a él en los comentarios o email intercambiados durante la resolución.
-
Explica de forma clara y precisa como reproducir el error. Describe paso a paso cómo reproducir el error, además de los datos relevantes que introdujiste en la aplicación. Muchas veces la culpa de los bugs es de una mala validación de los campos de entrada, por eso siempre que puedas y no sean confidenciales aporta esos parámetros y datos que empleaste.
-
Debes ser muy específico centrándote en el problema. Resume de forma concreta el error y no mezcles en la misma incidencia distintos bugs. Crea para cada error una nueva tarea para resolver.
-
Intenta usar la misma plantilla para los errores que reportes. Si no dispones de una herramienta especifica de seguimiento de incidencias, crea una sencillo informe que contenga los siguientes campos:
-
Informador: tu nombre o email para que se ponga en contacto contigo.
-
Producto: aplicación o producto en el que encontraste el error.
-
Versión: más importante de lo que crees, indica claramente el número de versión.
-
Plataforma / Sistemas operativo: donde ejecutaste o consultaste la web.
-
Prioridad: indica la importancia del bug, será útil para ir seleccionando de la pila los más prioritarios
-
Alcance: bloqueante, critical, major, minor, trivial o mejora. Según el orden de magnitud que afecte al producto.
-
Estado: según el estado que se encuentre el bug (abierto, comprobado, solucionado, no solucionado, en desarrollo, etc...)
-
Asignado a: la persona que se va encarga de solucionarlo.
-
URL: de la localización del bug
-
Resumen: una breve descripción del problema de no más de 60 palabras
-
Descripción: informe más detallado del error que conste de los pasos para reproducirlo, el resultado esperado de la aplicación y del resultado erróneo que se obtiene actualmente.
Típicamente los informes de bugs suelen ser de alguna de estas categorías: errores de código, de diseño, nuevas sugerencias de mejoras, erratas en la documentación o en los manuales o problemas de hardware.
Recuerda que cuando te encuentres con un bug, lo mejor es escribir la incidencia inmediatamente para no olvidar ningún detalle que se nos puedan escapar. Además, prueba a reproducir el bug varias veces hasta que veas claramente cuales son los pasos hasta llegar al error. Siempre, se educado en la redacción del bug.
En Genbeta Dev | Bugs en el software
