Cómo reportar bugs o errores

Una guía que nos muestra la mejor manera de hacer que nuestros reportes de bugs o errores a proyectos de software libre sea más útil y eficiente

Dentro del mundo del software libre, que la comunidad que usa el software reporte errores o bugs encontrados, hace que el software mejore y sea más fiable y seguro en distintos escenarios de uso y distintos equipos.

Reportar errores a la comunidad que desarrolla software es muy importante y es una tarea necesaria, pero ¿de qué manera hacer eso de forma que sea útil y eficiente para las personas que los reciben y que tienen que corregir los errores siguiendo esos reportes?

Este artículo te da algunas pistas para enviar esos importantes reportes de errores y que sean útiles y faciliten la tarea a quienes los reciben.

Este artículo es una traducción/adaptación de un artículo escrito en inglés por un joven desarrollador finlandés que publicó en su blog. En el que comparte su experiencia como desarrollador y como persona que envía informes de bugs, para hacerlo de manera efectiva.

Encontrar el sitio adecuado para reportar errores

Puede que a veces no sepas dónde reportar el error que has encontrado

El propio autor, indica que el sigue estas rutas:

1. Si sucede con un software específico, repórtalo a la comunidad que desarrolla ese software específico.
2. Si sucede con el hardware en torno a varios programas, repórtalo al repositorio de controladores de ese hardware.
3. Si aún tienes dudas, lo mejor es preguntar en los canales de comunicación relacionados con el software/hardware (Matrix/IRC, listas de correo, repositorio en un servicio git, etc)

Normalmente alguien te indicará el mejor sitio. Así que no tengas miedo de preguntar si realmente no puedes averiguar dónde se debe enviar ese informe.

Sigue siempre el esquema

Ninguna de las cosas que digo aquí son buenas si no sigues la plantilla de informe de errores dada. A menudo, los proyectos tienen su propia plantilla para enviar informes de errores.

Nunca está de más volverlo a repetir: sigue lo más fielmente posible esa plantilla.

Muchos informes de errores a menudo no son muy útiles porque simplemente ignoran la plantilla. La información realmente buena se oculta dentro de algo (generalmente una diatriba) y los desarrolladores, a menudo está revisando muchos informes de errores, especialmente en proyectos grandes. Simplemente no hay tiempo para leer la larga diatriba y descifrar cuál es realmente el problema.

Proporciona los detalles que solicita la plantilla, coloca todo lo demás en la sección «información adicional» al final del informe.

Si no existe una plantilla predefinida, este es un buen ejemplo a seguir a la hora de enviar informes de errores.

Resumen del bug

¿Cuál es el error en realidad? ¿Qué falla? ¿Qué crees que está mal? ¿Quizás es una funcionalidad?

Escribe un breve resumen de lo que está sucediendo, pero proporciona más detalles que simplemente «la pantalla no funciona».

Por ejemplo:

La pantalla se apaga cuando abro <este programa>. Y también puedo escuchar los ventiladores de mi equipo que empiezan a girar muy rápido antes de que todo se quede congelado.

Esto sucede también con otras aplicaciones, que parecen usar <tal librería>.

Básicamente, proporciona la situación en la que ocurrió el error, pero de manera muy concisa. Puedes escribir más detalles en la sección «Información adicional».

Pasos para reproducir el error

Para corregir un error, el desarrollador debe poder reproducir dicho error. El desarrollador necesita ver qué está pasando, qué sale mal. Luego, pueden depurar el software con herramientas existentes.

Por lo tanto, escribe en el informe de error qué hiciste para que ocurriera. No tienes que escribir todo el día desde que te levantaste de la cama, pero trata de apuntar más o menos 5 pasos antes de que ocurriera el error. Además, debes anotar si podrías hacer que el error vuelva a ocurrir.

Por ejemplo:

1. Actualicé mi PC
2. Reinicié el PC
3. Abrí la aplicación
4. Cuando al realizar <tal tarea>
5. El equipo se queda congelado

Reinicié el PC e intenté realizar la misma tarea y se volvió a congelar. A la tercera vez todo pareció que funcionaba correctamente.

Esto ya le da al desarrollador mucha información. Se puede suponer que antes de la actualización, el realizar esa tarea con la aplicación no hacía que se congelara el PC. Entonces el problema está en algún componente de actualización. Sin embargo, no sucede siempre, por lo que probablemente haya algún problema extraño. O algo más… ¡Empiezan a fluir los jugos creativos!

Básicamente, ofrecer instrucciones paso a paso sobre cómo hacer que el error ocurra en su PC. Además, si puedes, menciona con qué frecuencia ocurre el error.

Información del sistema

Esto es MUY importante, y aquí hay un par de comandos para sistemas GNU/Linux que puedo darte para obtener buena información.

Una muy buena opción es utilizar el comando inxi. Si no lo tienes instalado en tu equipo, instala esta pequeña utilidad para la línea de comandos que ofrece una información muy detallada de todo nuestro equipo y sistema.

Un simple inxi --full ofrece un log de información muy completo que puedes incluir en el reporte.

Asegúrate que la información que ofreces incluye los números de versión de todo y todos los datos necesarios. Sigue la plantilla, si existe, para ejecutar los comandos y la información del sistema si es necesario.

Información adicional

Si tienes alguna información específica que añadir, hazlo al final del archivo.

Puedes incluir, por ejemplo, si tienes conocimientos del fallo en otros sistemas, o si has leído algo relacionado con ello que pueda ayudar, o cualquier cosa que creas que puede ser relevante.

Registros

También es importante y útil incluir registros o logs del sistema, para ver si mientras se estaba ejecutando la tarea en concreto ha quedado alguna traza en nuestro sistema. Llamadas a interrupciones, ejecución de ciertas librerías, etc.

Si quieres comprobar si tu sistema ha registrado algo interesante, que pueda aportar información, puedes hacerlo mediante el siguiente comando:

journalctl --since="10 minutes ago"  > bug.log

Puedes cambiar el periodo de tiempo de 10 minutos a por lo menos 2 horas “2 hours ago” o algo similar. Ajusta el tiempo, y echa un vistazo al archivo bug.log para ver si hay algo interesante.

Si no hay nada que pueda resultar de interés, puedes omitir enviar ese archivo y preguntar si hay algún otro log o registro que deberías incluir.

El resultado final

Una vez seguidos los pasos y enviado un informe lo más completo que has sabido y podido, pueden pasar algunas de estas cosas:

1. El desarrollador pregunta por más información detallada si es que tienen algo en mente que pudiera provocar dicho problema.
2. El desarrollador no puede reproducir el error y te pide ayuda para solucionarlo, a menudo utilizando tal versión de de algo relacionado con el propio error.
3. El error ya ha sido solucionado pero tienes que esperar a que se actualice el software.
4. Quizás el sistema de reporte de errores te avisa que hay ya un reporte enviado sobre el mismo problema, por lo que no abras un nuevo reporte, añade información al ya existente con la información que has recopilado siguiendo los pasos anteriores.

Espero que esto sea interesante y te de una pauta o un procedimiento a seguir a la hora de informar de errores cuando te los encuentres al utilizar tu software libre preferido, ya sea sistema operativo, entorno de escritorio, aplicación, etc…

El reporte de errores es una de las tareas importantes, no dudes en ser riguroso, y respetuoso a la hora de reportar tus errores. Tus errores son muy importantes para ti, pero hay detrás una comunidad limitada de tiempo y recursos para solucionarlos, ten paciencia a la hora de exigir que se solucionen.

Reportando un error has dado un paso importante para su resolución y has apoyado tu proyecto de software libre preferido. ¡Enhorabuena!