El error más común en el ciclo de vida del bug

No pases por alto este paso clave al depurar el software.

En nuestro planeta, el insecto Mayfly tiene uno de los ciclos de vida más cortos. Después de la transición a la etapa adulta de su vida, generalmente se reproduce y luego muere en solo 30 minutos. ¿Qué pasaría si los bugs de software nacieran y se eliminaran de manera rápida y fácil?

Cuando los testers y los desarrolladores trabajan juntos de manera efectiva, el período de tiempo desde la creación de un incidente hasta su eliminación en el software es mínimo.

Aunque los bugs nunca pueden prevenirse al 100 % y el software nunca estará 100% libre de errores, existen buenas prácticas que los equipos pueden adoptar para que los errores en el software vivan solo por un breve período de tiempo y nunca lleguen a multiplicarse.

Un buen sistema de gestión de incidentes ayuda a garantizar que la mayoría de los bugs se encuentren y se solucionen mucho antes de pasar a producción.

Ciclo de vida del bug

Este es un boceto básico que resume una de las formas posibles de representar el ciclo de vida de un bug, del que hablé en nuestro e-book de automatización de pruebas funcionales. En realidad, podría haber miles de variaciones diferentes del ciclo de vida de un bug según el tamaño del equipo, la estructura organizativa, etc. pero, para nosotros, ¡este ciclo es básicamente una ley!

¿Cuáles son los errores más comunes en la gestión de incidencias?

Uno de los errores más típicos en la gestión de errores que el equipo de Abstracta ha identificado al trabajar con diferentes empresas durante más de 14 años en entornos tradicionales y ágiles, es cuando se corrige un bug y el desarrollador lo marca como cerrado.

Sin embargo, no debemos olvidarnos de verificar los incidentes. Primero, el tester lo informa y luego el desarrollador lo soluciona, pero la persona que finalmente debe determinar si se ha resuelto es el tester.

¿Qué sucede si el desarrollador cree que se ha ido, pero después de realizar más pruebas, todavía está allí? ¿Qué sucede si se ha creado un nuevo error?

Un tester de software siempre debe verificar que el fallo no exista para minimizar los riesgos.

Variaciones del ciclo de vida de los bugs

Hay otras variaciones que son válidas dentro de este entorno. Por ejemplo, puede tener a alguien que tenga la responsabilidad de revisar los incidentes que surjan y decidir cuáles arreglar y cuáles no.

Esta situación podría funcionar dentro del flujo anterior, ya sea el tester o el desarrollador que marque un error como “resuelto” o como “no se solucionará”. O bien a través de un acuerdo, el tester y el desarrollador podrían decidir cuál es la opción adecuada con un mutuo acuerdo.

En otro esquema, es posible que desee señalar cuándo volver a abrir un incidente y qué sucede una vez que se vuelve a abrir. O bien, un error antiguo simplemente aparecería como uno nuevo y comenzaría el ciclo de vida nuevamente.

La gestión de incidentes es un indicador básico de la eficiencia de un equipo de desarrollo y, además, es un área clave donde se puede ver si los testers y los desarrolladores se sienten parte del mismo equipo o no. Ambas partes deben hacer su parte para trabajar en equipo.

No solo los desarrolladores deben trabajar para colaborar con los testers. Los testers por su parte, deben compartir una visión global centrada en los objetivos de todo el equipo y comprender que no todo se puede arreglar.

Me encantaría escuchar tus comentarios respecto al ciclo de vida de los bugs y si sigues un esquema similar u otro que te resulte más útil o adecuado, así como los problemas típicos a los que te enfrentas, etc.