Debido a que durante el desarrollo de cualquier producto software se identifican un gran número de defectos, en muchos casos de alta prioridad o prioridad crítica, un equipo para la revisión de defectos (Defects Review Team) es esencial en cualquier equipo de testing.
Un DRT (Defects Review Team) proporciona una rápida y eficiente respuesta a un defecto en cualquiera de nuestros entornos y garantiza una oportuna solución. El equipo estará integrado por los siguientes miembros:
- Responsable del equipo de desarrollo (Development team leader).
- Jefe de proyecto (Project manager).
- Responsable del equipo de pruebas (QA team lead).
- Cliente (Opcional). Es importante que el cliente forme parte de este equipo, aunque no siempre es posible su participación.
Plan de acción:
Lo primero que debemos hacer es establecer un plan de acción. Podemos establecer reuniones semanales para discutir los defectos más importantes…pero claro, una revisión semanal en algunos casos puede no ser suficiente, y una reunión diaria puede ser deficil de conseguir. ¿Que podríamos hacer? Podemos establecer como norma, una reunión semanal y después, cada miembro del equipo se debe comprometer a revisar diariamente los defectos. En caso de que sea necesario se pueden establecer reuniones ocasionales si fuese requerido.
Nuestro plan de acción:
- Todos los miembros del DRT deben de ser notificados, por ejemplo via email, de todos los defectos de prioridad alta y crítica.
- Semanalmente se discuten los defectos más importantes. Los defectos ya existentes se revisan para asegurarnos que el defecto no está duplicado.
- Si el defecto es válido, se introduce en nuestro DTS (Defect Tracking System) como “OPEN” (más tarde serán asignados por el responsable de desarrollo).
- Se revisan los defectos críticos que deberían haber sido arreglados y que aún no están solucionados. Se analizan las causas y se establece un plan de acción, ¿como podemos arreglar lo antes posible?.
- Haremos análisis a largo plazo…¿Que acciones debemos tomar para que defectos así no vuelvan a repetirse?.
- Debemos de establecer timelines en la resolución de defectos a corto plazo.
Javi, excelente forma de plasmar esta buena práctica en testing de software.
Sólo comentar una experiencia personal: Perdida de defectos.
Si bien es cierto, para una buena gestión de defectos, lo mínimo que deberíamos demandar es una buena herramienta de reporte/seguimiento/gestión de los mismos; pero sobretodo una buena práctica (tal como la que señalas) de la toma de decisiones respecto a los defectos reportados para una aplicación en concreto.
Es obvio que no todos los defectos tienen la misma criticidad (aunque no por ello el equipo de Testing/QA debe dejar de reportarlo – una política que me ha costado que el equipo de desarrollo lo acepte), pero precisamente basado en ello y utilizando los diferentes medios de comunicación (email, reportes, actas de reuniones, etc.), trabajamos de forma coordinada con Desarrollo y Producto en la resolución y/o validez de cada defecto. Incluyendo además una valorización de la afectación de los mismos en la estabilidad de la aplicación y el coste en tiempo de desarrollo y posterior QA.