El arte de reportar un bug
Al
estar trabajando muy de cerca tanto con testers como con
desarrolladores, y cumpliendo diversas funciones de un lado y del otro,
siempre tengo presente esta imagen de Andy Glover que describe la información que es necesaria al momento de reportar un incidente:
Reportar un incidente con falta de información / datos / contexto hace que cuando el desarrollador encuentra "un hueco" para atender dicho incidente, no pueda reproducirlo y solicite más feedback. Esta ida y vuelta es típica entre los equipos de testing y desarrollo, y es algo que vale mucho la pena mejorar.
¿Cómo hacemos entonces para aplicar estos consejos y mejorar?
Aca les dejo el top 3 de mis opciones preferidas:
1) Usar templates
Tener templates propios con la información exacta que un desarrollador necesita para encontrar el error.
Muchas veces es necesario categorizar los erroes para tener dentro de cada "tipo de error" la información que se necesita.
2) Automatizar / Usar herramientas
Siempre que el bug encontrado sea encontrado por un test automático, dependiendo de la herramienta, tendré fácil acceso a: datos, pantallas, pasos ejecutados, ambiente, hora, etc. Esto facilita enormemente la capacidad de reportar y reproducir un incidente.
3) Medir
Este es, como decía en su post hace unos años Santiago Bilinkis, "un método mágico para mejorar casi cualquier cosa". Si usamos alguna herramienta de bug tracking o simplemente usamos el email para reportar errores, una buena forma de mejorar sería medir y observar cuántas idas y vueltas existen, cuánto tiempo tarda el desarrollador desde la primera vez que intentó corregir el error y cuando lo solucionó (claro que esto es más fácil de averiguar con un gestor de incidentes que con el email). De ese experimento seguro obtendremos conclusiones e ideas para mejorar.
1. Educar: educar al tester en aprender a categorizar el incidente, cual es su severidad. Hay que lograr que el tester pase de elegir una severidad al azar a realmente entender como funciona el sistema y poder dimensionar la magnitud del bug.
2. Para mejorar la interaccion creo que es importante tambien mostrar valor. Con esto me refiero a si el dev encuentra de valor y de calidad los bugs reportado por X tester seguro que va a tener una mejor interaccion que con un tester Y que reporta de mala calidad. Es importante de ambos lados mostrar respeto por el trabajo del otro y desde mi punto de vista respeto se demuestra trabajando en serio:)
3. Dar seguimiento de los bugs, es una tarea molesta pero es importante conocer en todo momento cual es el status actual de la calidad del sistema:) No esperar a un momento X en el cual se disponga de ancho de banda para hacer bug fixing.
4. Automatizacion de bugs severos/prioritarios, tan pronto como sea posible agregar a la queue de automation este tipo de bugs, dados que son candidatos top para repetirse en una nueva iteracion.
Reportar un incidente con falta de información / datos / contexto hace que cuando el desarrollador encuentra "un hueco" para atender dicho incidente, no pueda reproducirlo y solicite más feedback. Esta ida y vuelta es típica entre los equipos de testing y desarrollo, y es algo que vale mucho la pena mejorar.
¿Cómo hacemos entonces para aplicar estos consejos y mejorar?
Aca les dejo el top 3 de mis opciones preferidas:
1) Usar templates
Tener templates propios con la información exacta que un desarrollador necesita para encontrar el error.
Muchas veces es necesario categorizar los erroes para tener dentro de cada "tipo de error" la información que se necesita.
2) Automatizar / Usar herramientas
Siempre que el bug encontrado sea encontrado por un test automático, dependiendo de la herramienta, tendré fácil acceso a: datos, pantallas, pasos ejecutados, ambiente, hora, etc. Esto facilita enormemente la capacidad de reportar y reproducir un incidente.
Este es, como decía en su post hace unos años Santiago Bilinkis, "un método mágico para mejorar casi cualquier cosa". Si usamos alguna herramienta de bug tracking o simplemente usamos el email para reportar errores, una buena forma de mejorar sería medir y observar cuántas idas y vueltas existen, cuánto tiempo tarda el desarrollador desde la primera vez que intentó corregir el error y cuando lo solucionó (claro que esto es más fácil de averiguar con un gestor de incidentes que con el email). De ese experimento seguro obtendremos conclusiones e ideas para mejorar.
1. Educar: educar al tester en aprender a categorizar el incidente, cual es su severidad. Hay que lograr que el tester pase de elegir una severidad al azar a realmente entender como funciona el sistema y poder dimensionar la magnitud del bug.
2. Para mejorar la interaccion creo que es importante tambien mostrar valor. Con esto me refiero a si el dev encuentra de valor y de calidad los bugs reportado por X tester seguro que va a tener una mejor interaccion que con un tester Y que reporta de mala calidad. Es importante de ambos lados mostrar respeto por el trabajo del otro y desde mi punto de vista respeto se demuestra trabajando en serio:)
3. Dar seguimiento de los bugs, es una tarea molesta pero es importante conocer en todo momento cual es el status actual de la calidad del sistema:) No esperar a un momento X en el cual se disponga de ancho de banda para hacer bug fixing.
4. Automatizacion de bugs severos/prioritarios, tan pronto como sea posible agregar a la queue de automation este tipo de bugs, dados que son candidatos top para repetirse en una nueva iteracion.
http://blog.abstracta.com.uy/2013/03/el-arte-de-reportar-un-bug.html
No hay comentarios.:
Publicar un comentario