Errare humanum est

(Imagen: Geek and Poke de Oliver Widder)

Nadie es perfecto, ni siquiera los programadores, y mucho menos los programas que hacemos. Es por eso que son necesarios nuestros amigos de control de calidad, para decirnos - con cortesía- que nos hemos equivocado pero solicitando con insistencia que arreglemos lo que detectaron.  Sin embargo, la gente de control de calidad tampoco es perfecta y sucede con frecuencia que nuestros errores  (o bugs, en argot del programador) llegan hasta el usuario final, que suele reaccionar muy mal cuando algo no funciona como quiere:

"Estimado Perico: Nada en el sistema funciona como me dijeron que iba a funcionar y no puedo trabajar con un sistema en estas condiciones. Cuando trabajábamos con el sistema en Cobol no teníamos este tipo de problemas."

Correos de esa naturaleza llegan a la bandeja de los desarrolladores, incluyendo a Jefes de Proyecto, Gerentes y demás interesados entre los destinatarios. Ahora, si el programador es novato y la gente de calidad es despistada este tipo de correos puede crecer en número y frecuencia; dejándonos con la bandeja de entrada llena y muchos bugs sin control.

Es por eso que todo equipo de desarrollo necesita una base de datos de bugs para tener control del estado de la aplicación: saber cuánto hemos reparado, cuánto nos falta reparar y quién está haciendo ese trabajo. Puse base de datos en negrita porque dada la importancia de esta tarea no podemos confiar en hojas excel ni archivos txt (aquí donde trabajo lo hemos intentado y hemos fracasado rotundamente). Ahora en la empresa estamos empezando a  usar Bugzilla para el control de errores, y nos está yendo bien: es bastante completo y además es gratuito :D.

Quería comentarles también que gracias a la recomendación de un compañero de trabajo -asiduo lector de este modesto blog- llegué a un artículo de Joel Spolsky sobre sistemas de  reporte y control de incidencias. Les listo algunas ideas que me parecieron interesantes:

• Un buen reporte de bugs debe tener 3 partes: Pasos para reproducir el bug, resultado esperado y resultado real. Por lo general los usuarios mandan correos poco descriptivos ( del tipo "¡nada funciona!", o con un screenshot y el asunto de "Arréglalo"). En el sistema de  reporte de errores (como nuestro Bugzilla) se debe registrar toda la información necesaria para que el programador pueda hacer su trabajo.

• Los bugs deben ser responsabilidad de una persona. En otras palabras, en todo momento debemos saber quien se está haciendo cargo del bug. Inicialmente puede estar asignado al Jefe de Proyecto, que puede derivarlo al Desarrollador Perico que luego lo asigna al Desarrollador Paco debido a que el error era en el módulo que él desarrolló. Siempre se debe conocer al responsable del bug, de modo que podamos echarle la culpa cuando persista el error xD.

• Sólo el que reporta el bug puede cerrar el bug. Porque sólamente el que registró el bug sabe a ciencia cierta que es lo que estaba mal. Una vez que el desarrollador termine de construir la solución, el registrador del bug (que puede ser personal de Control de Calidad o Usuarios finales) debe dar el visto bueno. Caso contrario, a continuar con las reparaciones xD.

• El sistema de registro de bugs debe ser masivamente usado. Para esto, Spolsky nos da algunos tips: Si eres desarrollador, sólamente repara bugs que te han asignado por el sistema. Si eres personal de Control de Calidad, sólamente reporta bugs por el sistema. Si eres Jefe de Proyecto, asigna bugs a tus desarrolladores por el sistema. De esa manera dejaremos de usar excel y emails para pasar a algo más organizado.

En todos estos puntos Bugzilla nos va a ser de ayuda. Ojalá nos funcione: si le funcionó a Facebook y a la NASA creo que a nosotros nos puede ser útil xD.

Hasta otra!!