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.

Advertisements

"Gestión del testing" – Próxima reunión de la Comunidad AGILE Córdoba

El testing de software es una actividad que no detiene su crecimiento y sin importar el contexto en el que se desarrollen aplicaciones o sistemas, el testing es uno de los pilares fundamentales para el aseguramiento de calidad.

Sin embargo, aunque muchos aprendieron a hacer testing en distintos niveles, un gran dilema es, cómo en las metodolgías Agiles podemos organizar un proceso de testing sabiendo de los muy cortos plazos del proceso de desarrollo y con muy bajas posibilidades de realmente hacer aseguramiento de calidad.

Muchos proponen la automatización hasta en sus más mínimos detalles, desde el requisito hasta la aceptación, pasando por el código, la integración y quizás el testing funcional.

Personalmente creo que el testing por si mismo, aunque está ligado a la automatización, no necesariamente está ligado al aseguramiento de la calidad y todo caso ambos, testing y calidad están ligados al factor escencial que es la comunicación.

Sin ir más allá quisiera referirme a un artículo anterior en este mismo blog donde expreso lo siguiente:

con respecto a Testing-Agile James Bach nos dice:

“… cuando di con Agile-Testing encontré un punto de vista desde los desarrolladores que descubrieron Agile y pensaron que esto se trataba de automatizarlo todo y eso es lo que hacen. Por lo tanto solo hablan de herramientas y herramientas y mencionan todas las que conocen.
O lo que realmente significa es, hagamos ingeniería utilizando las habilidades para testar rápidamente las cosas realmente importantes, de una forma sistemática y organizada. El nucleo principal de Agile-Testing se llama SKILLS…………………………………….. la automatización es importante, pero no confundamos Testing con herramientas.

Testing no se trata de herramietas, sino de humanos que pueden hacer algo con las herramientas.”

De mi artículo AGILE con ‘a’ y con ‘A’

Próxima reunión: Jueves 2 de septiembre, 18:30 hs.
Sede:  INTI Córdoba, Av. Vélez Sársfield 1561 (frente a Plaza De Las Américas)

Nota Importante:

  • Por razones de seguridad en sede y espacio, inscribirte para participar
  • Debido a la naturaleza de la actividad, rogamos ser puntuales para facilitar la organización y poder participar y aprovechar los juegos en su totalidad.