Workflow vinculado con el Ciclo de Vida de un Bug según modelo definido.
Situación a resolver
“ … hay discusiones entre los miembros del equipo de proyecto (business analyst ó developer ó tester) porque no saben / no se acuerdan cuál es el estado que deben fijarle a un BUG ya sea cuando lo crean, lo asignan, lo toman, lo aceptan, lo rechazan, lo resuelven, lo prueban, lo vuelven a reactivar, lo cierran. Ésto provoca que muchas veces se salteen la acción de ‘cambio de estado’ y envían un correo electrónico comunicando una situación determinada o directamente no modifican el estado del BUG, olvidándose que ésta acción ocasionará que la información que esté proveyendo un gráfico antes diseñado que lo estará siguiendo el Project Manager y/o el Cliente no sea real y/o que toda consulta/reporte que se elabore, no responda a la realidad del proyecto…“
Condiciones previas
Para cumplir con este objetivo, las precondiciones son:
- Saber el modelo que se ha definido para el proyecto en el que esté asignado;
- Haber tratado entre los miembros del equipo de proyecto el correspondiente workflow del ciclo de vida del bug;
- Conocer qué gráficas y consultas están elaboradas e incluídas en el panel que servirá para hacer el seguimiento del proyecto;
Para todo ésto, hay que tener presente que el estado que se le establezca a una work item (elemento de trabajo) permite mejorar la calidad de trabajo y de comunicación entre los miembros del equipo, ya que de esa manera todos estarán conscientes del estado de situación del producto que se esté desarrollando, el Project Manager podrá realizar un seguimiento adecuando, y el Cliente y/o Stakeholders estarán al tanto de la evolución del desarrollo.”
Aquí te muestro el Workflow correspondiente al Ciclo de Vida según el Modelo que se haya definido
Una vez corregido un error (bug), hay que actualizar su estado de flujo de trabajo (workflow). Las opciones de estado por las que transicionan varían según el proceso que utilice, es decir, se pudo haber definido al proyecto bajo los siguientes modelos: Scrum, Agile o CMMI. Las siguientes imágenes muestran el ciclo de vida (lifecycle) del flujo de trabajo definido para poder administrar y entender la transición por la que puede/debe pasar el error para los procesos antes indicados (Agile, Scrum y CMMI).
Para los errores (bugs) de Scrum, simplemente hay que cambiar el estado de Committed (Comprometido) (similar a Active (Activo)) a Done (Hecho). Para Agile y CMMI, primero se debe resolver (resolve) el error, lo que indica que el error se ha solucionado (fixed). Normalmente, la persona que creó el error verifica la solución (fix) y actualiza (updates) el estado de Resuelto (Resolved) a Cerrado (Closed). Si se ha encontrado más trabajo después de que se haya resuelto o cerrado un error, se puede reactivar configurando el Estado como Committed (Comprometido) ó Active (Activo).
Bug
Verificar una solución (fix)
Para verificar una solución, un developer o tester debe intentar reproducir el error (bug) y buscar un comportamiento inesperado adicional. Si es necesario, deben reactivar el error. Al verificar una resolución de error, es posible que el error no se haya solucionado por completo o que no esté de acuerdo con la resolución. En este caso, las buenas prácticas recomiendan discutir el error con la persona que lo resolvió, llegar a un acuerdo en caso de confirmarse como tal y, posiblemente, volver a activarlo. Si se reactiva el error, se aconseja incluir las razones en la descripción del error.
Cerrar un error (bug)
Se cierra un error una vez que se verifica como corregido (fixed), sin embargo, también se puede cerrar un error por alguna de las siguientes razones:
Aplazado (Deferred)
Aplazar una solución (fix) hasta la próxima versión del producto.
Duplicado (Duplicate)
El error ya se ha informado, puede vincular cada error con el tipo de enlace Duplicar / Duplicar y cerrar uno de los errores.
Como diseñado (As Designed)
La característica funciona como fue diseñado.
No se puede reproducir (Cannot Reproduce)
Las pruebas demuestran que el error no se puede reproducir.
Obsoleto (Obsolete)
La característica del error ya no está en el producto.
Copiado a Backlog (Copied to Backlog)
Se ha abierto una historia de usuario o PBI (Product Backlog Item) para rastrear el error
Siempre es una buena idea describir cualquier detalle adicional para cerrar un error en el campo Historia (History) que luego al Guardar, se verá reflejado en el campo Discusión (Discussion field) para evitar confusiones futuras sobre por qué se cerró el error.
Monitorear el estado de los errores, las asignaciones (assignments) y las tendencias (trends).
Se puede hacer un seguimiento (track) del estado de los errores, las asignaciones y las tendencias mediante consultas que luego se pueden convertir en gráficos y agregarlos a un panel (dashboard). Aquí una mención: para incluir un gráfico en el panel deberá ser una consulta del tipo plana (hay tres tipos de consultas).
Aquí te dejo algunos ejemplos de indicadores que se pueden mostrar:
Indicador 1: Bugs según estado más fecha Changed & Resolved
Bugs detectados con sus correspondientes estados y fechas en las que se hizo una modificación y se los resolvió. Desde este widget se puede conocer la Test Suite donde se encuentra, además de poder acceder al mismo y conocer el Test Case afectado.
Para armar este indicador hay que seleccionar el siguiente widget
Y por supuesto, tener la QUERY preparada.
Indicador 2: Bugs preexistentes y Aprobados
Para ciertas ocasiones es necesario tener seguimiento de bugs que ya tenía la aplicación para diferenciarlos de los nuevos que se identifiquen.
Para armar este indicador hay que seleccionar el siguiente widget
Y por supuesto, tener la QUERY preparada, por ejemplo:
Query básica: Bugs_Estado=Aprobado
Tipo de Consulta: Lista plana de elementos de trabajo
Campo: Iteration Path | Operador: Pertenece a | Valor: [proyecto]\Sprint 1
y Campo: Work Item Type | Operador: Contiene | Valor: Bug
y Campo: State | Operador: = | Valor: Approved
Si te ha gustado el artículo, compartilo por favor entre tus contactos y deja un comentario en mi twitter @testingbaires,
Muchas gracias por seguirme, nos vemos en el próximo artículo, carpediem
