Los sistemas de gestión de errores (o "bug trackers") son cuellos de botella, y perpetúan el continuo idea y vuelta entre testers y desarrolladores, además de requerir de mucha documentación para mantenerlos.
Alberto Gutierrez comparte una interesante reflexión sobre cómo crear el mejor sistema de gestión de errores: ¡dejar de reportar errores y empezar a escribir pruebas automatizadas!
El ciclo de vida estándar de un bug es más o menos así: un tester de QA encuentra un error en la aplicación, crea un nuevo reporte de bug en el bug tracker y se lo envia al desarrollador, quien a su vez, ni bien soluciona el bug, lo envia de vuelta al tester, quien a su vez notifica al dueño del producto y luego cierra el bug.
En la teoría este proceso suena bien, pero tiene varias desventajas:
- Problemas de comunicación. A veces la descripción del bug es pobre, o el desarrollador malinterpreta el problema.
- Pruebas de regresión. El proceso requiere de idas y vueltas de código entre desarrollo y QA, lo que ocasiona problemas de versionado y duplica el esfuerzo de testing.
- No es robusto. El proceso no garantiza que el error no vuelva a aparecer en el futuro.
- Burocracia. Los sistemas de bug tracking tradicionales cambian el foco de la calidad a la burocracia.
La solución a estos problemas es bastante simple. Cuando alguien encuentra un bug, inmediatamente escribe una prueba automatizada que falla sobre el bug descubierto. Este mecanismo tiene varias ventajas:
- Desaparecen los problemas de versionado, todos trabajan en el head del código.
- Se garantiza que el bug no vuelva a aparecer sin ser detectado.
- Se elimina la ambigüedad sobre cuál es el bug exactamente.
- Se elimina burocracia.
- Consolida las actividades de desarrollo en un único lugar, el código.
Obviamente también hay desafíos a superar para cambiar a este proceso en donde no se necesita de un bug tracker:
- Se necesita un sistema de construcción automatizado. La construcción del proyecto tiene que estar corriendo todas las pruebas automatizadas, de manera que cuando se agregue una nueva prueba por un bug, la construcción falle y el equipo de desarrollo pueda decidir corregir el error en el momento, o ignorarlo por un tiempo (de esta manera sabremos que todas las pruebas ignoradas son bugs sin arreglar).
- Se necesita cooperación. Los desarrolladores y los testers tienen que trabajar juntos para crear las nuevas pruebas ni bien aparezca un bug. Se necesita tener testers con habilidades de programación.
- Se necesita disciplina. Los equipos tienen que entender que se debe crear una prueba por cada bug encontrado, sin excepción. Y cada vez que se rompe la construcción, la prioridad es solucionarlo.
- Se necesita organización. Las prueban tienen que crearse con criterio y usando alguna nomenclatura en común.
En resumen, en mi opinión el futuro de la gestión de errores es eliminar los bugs trackers tradicionales y toda la burocracia. Para lograr esto hay varios desafíos; si tienen las habilidades, las herramientas y el equipo para superar estos desafíos, podrían pensar seriamente en deshacerse del viejo sistema de gestión de errores.
