¿Qué hicimos para bajar los bugs en el equipo?

Los bugs son un problema común en el ámbito de desarrollo. Cuestan plata a nosotros y al cliente. También afectan el enfoque que tenemos en los desarrollos actuales, disminuyen nuestra motivación y afectan la confianza del cliente y la propia del equipo.

Hace un tiempo en nuestro equipo tuvimos un pico de ocurrencias de bugs. Fueron más de los que podíamos manejar. Luego de apagar el incendio y calmar a la fiera nos sentamos con el equipo a analizar por qué pasó esto. La idea era tomar esta experiencia no como un fracaso, sino como aprendizaje.

No queríamos volver a pasar por esta situación, por lo que nos preguntamos ¿qué podíamos hacer en ese momento para evitar un futuro caótico? Hicimos una lista de los últimos bugs que habían surgido. Vimos que la mayoría eran de frontend, algunos eran por no tener en claro los requerimientos desde un principio y otros por no tener bien clara la definición de terminado de las historias. Con esto en mente hicimos un par de experimentos para el día a día, y ver si esto ayudaba a reducir la cantidad de bugs:

TDD en Frontend:

Queríamos buscar una herramienta para testear en front así como las herramientas que tenemos para hacer desarrollo guiado por pruebas en el backend. Encontramos muchas y probamos usar Casper.js y QUnit.js. Con Casper llegamos a simular el uso repetido de la aplicación por parte de un usuario final. Nos resulto útil, pero no pudimos lograr que se corrieran en integración continua. Además eran costoso mantenerlos actualizados si hacíamos algún cambiar en la vista de la aplicación. Con QUnit, a diferencia de Casper, probamos la lógica de negocio que exponíamos en la vista. Pero tampoco encontramos la forma de que corrieran las pruebas de forma continua.

Buenas Prácticas de FrontEnd:

En lugar de centrarnos en corregir bugs decidimos reforzar la manera en que codeábamos en javascript y ccs para evitar que ocurran.
Realizamos una revisión de código de un proyecto y sacamos conclusiones. (Link a Podrías tener un código igual). Observamos que muchos de estos errores eran por el aprendizaje normal de un equipo nuevo. Con esto hicimos una charla técnica entre nosotros para compartir este aprendizaje.

DDT:

Tener una definición de terminado para las historias de un proyecto es muy importante. ¿Por qué? Porque nos garantiza un marco de calidad para nuestro producto consensuado con el cliente (En nuestro caso, la aplicación debía ser reponsive y poder accederse en Internet Explorer 9).
Al no tenerla definida, el cliente nos pedía cosas que no sabíamos que previamente estaban acordadas.
Ahora en cada proyecto o iniciativa, consensuamos la DDT con el cliente antes de empezar el desarrollo. La imprimimos, la pegamos en nuestro tablero de Scrum y la tenemos cerca de cada uno de los integrantes del equipo.

Revisión cruzada de código:

Como vimos afectada la confianza del equipo decidimos hacer una revisión de las historias antes de darlas por terminada. ¿Para qué? Para aprender alguna buena práctica, analizar posibles fallas y dar feedback del código, entre otras cosas.
Esto resultó bastante útil y hoy todos estamos más al tanto del código que el equipo escribe.

Pedirle a alguien externo al equipo que pruebe la aplicación:

Algunos bugs que surgieron eran porque, al estar metidos en el código, pensábamos las pruebas de front como desarrolladores y no como usuario final.
Decidimos pedirle a alguien externo al equipo que pruebe las funcionalidades de la aplicación con el fin de tener un feedback más real de la experiencia de un usuario final.

Casos de test por escrito:

Muchas veces no teníamos en claro qué cosas probar y quedaba a criterio de quién la estuviera haciendo. Decidimos escribir todos los casos de prueba que se nos ocurrieran al momento de entrar en la plani. Esto permitió consensuar lo que teníamos que probar.

Y vos, ¿Qué hacés hoy para tener menos bugs? Contanos tu experiencia en los comentarios.