Agile testing y gestión de defectos

Desde hace un buen tiempo me encuentro en contra de la registración de defectos masiva, principalmente para entornos de desarrollo de software Agile, donde en resumidas cuentas un defecto pierde su razón de ser ni bien es corregido y verificado en el mismo Sprint de desarrollo.

Muchos me han preguntado, pero como hacen los desarrolladores en Agile para saber de que estamos hablando cuando alguien del team encuentra una anomalía, y mi respuesta siempre fue que el trabajo cara a cara evita cualquier tipo de aparato comunicacional y facilita no solo la corrección sino la mejora.

Por otro lado es cierto que existen muchos modelos de trabajo, como los tercerizados o los remotos, que impiden que los equipos se encuentren co-localizados y entonces ya existe la necesidad de algún sistema de gestión de defectos, sobre todo si hay personas que se dedican exclusivamente al testing de los items de trabajo.
Para estos esquemas también hay soluciones verdaderamente livianas, pero sin llegar a mencionar a ninguna, les diría que lo que prima es la real posibilidade contactarnos entre desarrolladores y testers para hablar de los defectos, su severidad, impacto, priorización y soluciones posibles.

Los invito a intetar un esquema simplista, donde el tester detecta el defecto, lo ingresa en una cola de trabajo inmediato, el equipo en una reunión cercana analiza los defectos acumulados (cola de trabajo), prioriza y resuelve. Tomen fecha de ingreso del defecto a la cola y feche de verificación de la solución.
Tomen exáctamente los mismos tiempos para un defecto que ingresa por una herramienta de gestión de defectos y comparen. Luego me cuentan.

Por lo pronto comparto un interesante artículo que habla de un método de gestión de defectos utilizando la automatización de pruebas como herramienta de evaluación del defecto y entidad documentacional, donde lo que se gana es un activo de software (test case automatizado) y capacidad de repetir la ejecución de la prueba las veces que se requiera.

Este punto de vista es muy efectivo y soluciona enormemente varios problemas a la vez, como la falta de cobertura por caminos alternativos significativos, aumenta el volumen de pruebas de regresión fiables, la registración del defecto, etc.

Source: STAREAST: Agile testing and defect tracking.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s