sábado, marzo 10, 2007

Como tratar un bug

Todos hemos lidiado con bugs, nuestros o de terceros, en proyectos en desarrollo o en proyectos cerrados, los hemos visto como usuarios de software y tambien como desarrolladores.

Los desarrolladores y los usuarios hemos aprendido que el software no es perfecto, que existen bugs y también service packs. Es cierto que nadie quiere ver esos bugs, pero más importante, nadie los quiere por segunda vez.

Así que aquí estan los 5 puntos de Miguel Madero para lidiarn con bugs (desde el punto de vista de desarrollo).
1. Tener un buen sistema de log.
Lo peor es que el único que puede reproducir el error es el usuario final, pero ¡No sabe como hacerlo!.
2. Revisar frecuentemente ese sistema de log o implementar un sistema de alertas. Los usuarios no van a venir a decirte que errores hay (a menos que sea muy grave) ellos aprenden a vivir con ellos y esperan que algún día se arreglen sólos. Muchas veces ni siquiera estaran concientes de que hay un bug, pero el análizar la información del sistema de log te puede ayudar a corregirlo antes de que se haga costumbre.
3. Habla con tus usuarios.
¿Qué les parece el software? ¿Qué problemas tienen? ¿Qué los hace sufrir cuando usan el software? Estos es muy importante y junto con la informacíón del log puedes encontrar el problema y su causa. Tambien te darás cuenta que muchas cosas que ellos piensan estan mal, simplemente son resultado de una mala capacitación o que no saben como usar cierta funcionalidad. Dependiendo del tipo de sofware se pueden usar tecnicas como reuniones de grupo, foros de discusión, apoyo de usuariso expertos, etc para mitigar esos problemas que por cierto no son el punto de este post.
4. Confirmar que encontramos el bug.
Estan pensando "una vez encontrado, correr a codificar un fix directamente".... NOOOOOOOOOOOOO, no hagan eso (en casos muy sencillos con eso terminaríamos). Hay que estar concientes que hasta este punto sólo hemos encontrado una probable causa y tal vez sólo un posible problema. Lo primero es crear una nueva prueba (vean mi post de TDD) que demuestr el bug. Esta es realmente una de las formas más sencillas de empezar a usar TDD. Para desarrolladores que nunca han usado esta buena práctica, la idea es que antes de codificar creemos una prueba que falle, luego hagamos la prueba pasar, lo cual garantiza que se haya cumplido el requerimiento o parte del requerimiento a probar.
Bueno un bug es finalmente un requerimiento más: "arreglar el problema de....". Así que usamos TDD de la misma forma que con cualquier otro. Aquí es más sencillo porque lo puedes hacer de manera aislada, es decir, no tiene que estar para todo el proyecto, sólo para parte del código, en este caso ya tienes también una idea (gracias al log y la platica con tu usuario) de como hacer una prueba que falle.
Aquí es donde vale la pena algo de código. El bug es el siguiente, el usuario dice que la aplicación esta calculando mal la suma de 2+2. Tu sabes que tienes una clase que hace esa suma, por lo que ese código es el que probaremos.
[TestMethod]
public void TestTwoPlusTwoIsFour()
{
MiClaseSumador sumadora = new MiClaseSumador();
int result = sumadora.Add(2,2);
int expected = 4;
Assert.AreEqual(result,expected);
}

En esta ocasión el log no nos hubiera ayudado mucho. Por otro lado el usar TDD fue muy sencillo en este caso, porque ya existía la clase y metodos a probar. Cuando no se esta acostumbrado a hacer pruebas al estilo TDD lo primero que hechan de menos el intellisense porque cuando escriben algo como "sumadora." el IDE no sabe que metodos hay porque no existen, ni que parametros espera, etc. Bueno cuando estamos corrigiendo un bug nos evitamos este problema haciendo la adopción de la técnica más fácil. Por otro lado, lo que realmente estamos probando antes de codificar no es en sí la clase, sino lo que hace la clase, así que pasamos al punto 5.

5. Corregir el bug identificado.
Una vez que tenemos una prueba que falla, sabemos que ese es el bug y simplemente hay que codificar algo para que pase la prueba. Una vez que la prueba pasa, no sólo estamos seguros de que efectivamente se corrigio el bug, sino más importante aún, de que no aparezca por segunda ocasión (claro hay que volver a correr esta antes de cualquier futuro release del software y mejor aún si se automatiza para que corra con cada checkin o cada noche por lo menos).


Claro que esta es una prueba sencilla, sólo quería ejemplificar. Por otro lado, la mayoría de los bugs podrían requerir de más de una prueba para garantizar que esta corregido, por ejemplo sumar 2,3 o algo distinto.

Otros puntos a notar.
El bug debería quedar documentado, si se usa alguna herramienta como Team Foundation Server el bug deberá relacionarse con las pruebas para que automaticamente nos provea la Trazabilidad que piden MoProSoft o modelos así (que por cierto a veces es útil).
La prueba debe volver a correrse de vez en cuando y mejor aún si es en cada check in.
Es importante el tener una forma rápida de actualizar a los clientes para que este bug quede corregido, si es un website puede ser fácil si es Windows o Mobile algo como Click One o el Updater Agent pueden ayudar.

QUE GANAMOS
Estamos seguros de que lo que correjimos es efectivamente el bug encontrado y no una cosa distinta, la prueba garantiza que realmente podemos reproducirlo.
Estamos seguros de que si se vuelve a presentar, seremos notros los primeros en encontrarlos al correr de nuevo la misma prueba.
Aprendimos TDD
Corregimos el bug.
Trazabilidad del bug a la prueba y a la corrección

No hay comentarios.: