VSTS no viene con un workflow de testing por defecto. Cierto es que la flexibilidad de este nos permite implementar varios modelos que nos podrían valer. Lo que se pretende en este post es proponer un modelo, de que partir y hacer modificaciones hasta adaptarlo a nuestras necesidades. Para ello necesitaremos al equipo de testing, ponernos de acuerdo y respetar los términos.

Desde la perspectiva del desarrollador, el tester es un valioso compañero de equipo. Alguien que nos está ayudando a que nuestra aplicación cumpla los requisitos de calidad y que nos está haciendo, en cierta forma, un trabajo del que debemos estar agradecidos. Algunos testers cobran más que los propios desarrolladores, esto habla de su importancia. Si tenemos la suerte de contar con equipo de testing debemos tener una buena comunicación con ellos. Imaginad que si por el contrario no tenemos tanta suerte, todas las tareas de búsqueda de fallos, las tendremos que hacer nosotros. Desde el punto de vista del equipo de desarrollo el equipo de testing enriquece la calidad del software y optimiza el tiempo de desarrollo. Y a pesar de contar con testing unitario y de integración, esto no es un sustituto de un buen equipo de testing.

Al contrario que VSTS, Jira si tiene un workflow de testing definido, en cierta forma el workflow aquí presentado se basa en él.

 

Preparación y planificación del tiempo de testing

Cuando trabajamos con el equipo de testing, deberíamos ser cuidadosos en que el tiempo no se desaproveche. Para esto la comunicación es fundamental. Algunas cosas que debemos planificar son:

  • Cómo debe funcionar la aplicación. Definir alcance, kick off para explicar detalles .
  • Qué se va a probar.
  • Dónde están los recursos para testing: Cuentas, usuarios, etc.

Debemos tener una línea abierta del equipo con testing y que la comunicación fluya. Por ello es importante que miembros de testing estén en reviews con cliente. También a veces y si el trabajo del tester se está realizando en paralelo con el desarrollo de features a testear que esté en dailies.

 

Usar el kanban board, mas visual, rápido y práctico

¿Por qué usar un listado donde tenemos que mirar los estados y tipos en columnas cuando tenemos una tabla kanban muy configurable?

Para organizar la tabla kanban usaremos la opción de que los bugs estén a nivel de tareas en vez de PBI. Esto no permitirá crear PBI perennes, como “Bug Críticos”, “Bugs”, “Bug estéticos o mínimos”, los cuales podremos incorporar a todos los sprints o configurar sprints de resolución de bugs con ellos.

ConfigBugsTask

¿Por qué no los bugs a nivel de PBI? kanban board se volvería más confuso y muchos bugs no tienen la entidad suficiente en contraste con un PBI. Desaparecerían las columnas de committed y new.

¿Por qué no ponemos los bugs en PBI de features según en que feature fue detectado el bug? Tendríamos siempre de vuelta esos PBI en el kanban board haciendo el backlog más confuso. Nosotros lo probamos y al final buscar a que PBI pertenecía el bug era complicado incluyendo algunos qué no pertenecían a nada o varios PBI a la vez. Se perdía tiempo y al final no se hacia

PBIs

En la propia tarjeta podemos ver de un vistazo, por ejemplo:

  • Si alguien se ha asignado una tarea.
  • De qué tipo es.
  • A qué PBI pertenece.
  • Podemos configurar más parámetros como:
    • Número de la tarea.
    • Horas completadas. Recomendable ya que es algo que se nos olvida rellenar y en la tarjeta se ve rápidamente.
    • Cualquier otra cosa que acordemos y que sea útil, sin sobrecargar el contenido de la tarjeta.
  • Etiqueta de estado o información.

Card

En nuestra tabla, se mezclarán columnas propias de tareas como To do, In progress con las de New y Approved que son para bugs. Las columnas committed y Done son compartidas.

 

Reglas

Vamos a definir algunas reglas y explicar por qué tiene que ser así.

  • Solo testing cierra bugs. Porque el tester es el único que da fe de que algo está resuelto o terminado en la aplicación. Esto es que los bugs que terminemos y creamos resueltos permanecerán en committed hasta que el tester los verifique y los mueva a Done. Habrá excepciones como por ejemplo los bugs críticos que se generan al romper la build. Esto no es necesario que lo verifique el tester, nosotros sabemos que la build vuelve a funcionar.
  • Solo testing eliminaría bugs, a excepción de los bugs generados por la IC. Porque si el equipo borra bugs sin que el tester se entere este puede volver a recrearlos pensando que ese bug no existía con anterioridad. Podemos usar comentarios y etiquetas para indicar porque un bug debería ser borrado pero no lo borraremos nosotros. La eliminación de bugs se toma como algo extraordinario, lo normal es que no se eliminen nunca, solo cambian de estado.
  • Los bugs se crean en new y se aceptan por el equipo. El proceso de aceptación podría coincidir con el proceso de asignación y empezar a trabajar con él, esto es:
    • Vemos los bugs que están en new y elegimos uno por prioridad
    • Lo reproducimos y pasamos a Approved
    • Trabajamos en él manteniéndolo en approved
    • Terminamos la corrección y lo pasamos a committed
  • Todo cambio de estado no habitual o etiquetado, se explica en el apartado de comentarios. Por ejemplo, si se etiqueta un bug como rejected, se indica en comentarios el porqué.
  • Los bugs siempre acaban en la columna Done o de manera extraordinaria, eliminados, es la finalización del workflow. En dicha columna estos bugs pueden aparecer con distintas etiquetas que indican el estado en que acabaron su ciclo: Sin etiqueta (Terminado), not a bug, deferred, obsolete, duplicate, not reproducible…
  • Los bugs en Done, no vuelven a cambiar de estado nunca. Si se generara un error similar, se crearía uno nuevo. Esto implica que no haya regresión. Nosotros lo preferimos, ya que hay implica que haya buscar el bug, que igual esta en otro sprint. Para nosotros lo que ocurrió en un sprint se queda en ese sprint. En nuestro caso, la mas cercano a una regresión seria que el tester mueva el bug de la columna commited a la columna new (indicando que el bug no esta corregido con su correspondiente etiqueta)

 

Etiquetas

Usaremos etiquetas para describir o marcar algunos estados no habituales:

  • Deprecated / Obsolete: El bug no cuenta, al haber desaparecido la feature a la que hacía mención o por cambio de requisitos. Se indicará en comentarios el porqué. Se deja en committed para que el tester lo verifique y lo mueva a DONE
  • Duplicated: El equipo de desarrollo marca el bug como duplicated. En comentarios se indicará cual es el otro bug que duplica y, en su caso, el porqué.
  • CantReproduce: El bug no puede ser reproducido o el equipo de desarrollo no sabe cómo.
  • ReOpen: El tester rechaza que el bug este resuelto ya que ha encontrado evidencias de fallo las cuales indicará en comentarios.
  • Remove: El equipo pide al tester que borre el bug, la razón se indica en comentarios. Esto es un caso extraordinario, lo lógico será marcar el bug con una etiqueta y que siga el flujo. El tester decide si las razones del equipo son suficientes o correctas.
  • Retest: Etiqueta indica que un bug que fue ReOpen está nuevamente corregido. La utilidad de esto es que el tester pueda diferenciar los bugs que tiene que verificar nuevos de los que ya ha verificado pero rechazo. Indicar en comentarios que fue corregido.
  • Blocked: Bug bloqueado, indicar en comentarios la razón por la que el bug no se puede resolver temporalmente. Por ejemplo, hay que modificar otra parte del código u otro bug antes para resolver este.
  • NotABug: Indicar en comentarios porque no es un bug.

La estrategia de las etiquetas proporciona una excelente visualización en panel de lo que está ocurriendo con los bugs. Además son muy versátiles. Aunque hay que tener cuidado con crear demasiados tags y  respetar mayúsculas y minúsculas.

Untitled picture

 

Workflow

Flujo normal: Creación –> Aprobación –> Resolución –> Verificación

  1. El flujo normal si todo va bien es que el tester o el desarrollador (o incluso el cliente) creen un bug en la sección New del PBI con la gravedad correspondiente.
  2. El desarrollador verifica que efectivamente el bug se puede reproducir y pasa el bug a approved. Comienza a programar una solución.
  3. Cuando termina la resolución del bug se pasa a committed. Si hubiera alguna consideración se dejaría en los comentarios.
  4. El tester verifica el bug y lo pasa a Done. El tester es el único actor que puede pasar un bug a la columna Done, con la excepción de los bug autogenerados.

No aceptación de la creación de un bug: Creación –> Desaprobación del bug –> Eliminación/Aprobación

El flujo en el que hay un desacuerdo en la creación de un bug.

  1. El tester o el desarrollador crean un bug en la sección New del PBI con la gravedad correspondiente.
  2. El desarrollador no puede verificar que el bug se puede reproducir o no aplica y etiqueta el bug como CantReproduce,  Deprecated, Duplicated, NotABug o Remove. Describe en comentarios por qué ese bug no debería seguir adelante. Y deja el bug en la sección New.
  3. El tester verifica y comenta con el desarrollador el problema. Se elimina o se aprueba el bug. En última instancia el tester es el que decidirá sobre el estado del bug.

No aceptación de la corrección de un bug: Creación –> Aprobación –> Resolución –> Rechazo de la resolución del bug

El flujo en el que hay un desacuerdo en la corrección de un bug.

  1. El tester o el desarrollador crean un bug en la sección New del PBI con la gravedad correspondiente.
  2. El desarrollador verifica que efectivamente el bug se puede reproducir y pasa el bug a approved. Comienza a programar una solución.
  3. Cuando termina la resolución del bug se pasa a committed. Si hubiera alguna consideración se dejaría en los comentarios.
  4. El tester verifica que el bug no se ha corregido correctamente marca el bug como ReOpen y describe en comentarios el problema. El bug vuelve a la sección New.
  5. El desarrollador vuelve a verificar y desarrollar una solución para el bug. Pasa el bug a committed con la etiqueta Retest, eliminando la etiqueta anterior.
  6. El tester vuelve a verificar el bug y pasaría a reabrirlo o a pasarlo a Done.

Rejecting a bug

Bug no puede ser resuelto actualmente: Creación –> Marcar como bloqueado

El flujo en el que hay un desacuerdo en la creación de bug.

  1. El tester o el desarrollador crean un bug en la sección New del PBI con la gravedad correspondiente.
  2. El desarrollador verifica que el bug no se puede corregir. Esto puede deberse a que hay que corregir otro bug antes o que se necesita un desarrollo previo. El bug se marca como Locked y se describe en comentarios el por qué del bloqueo y qué se necesita para desbloquearlo.
  3. Una vez que se cumplan las necesidades para la resolución del bug se elimina la etiqueta.

De esta manera vemos que las columnas en las que se centra el desarrollador y el tester son distintas. El target del Tester es la columna New donde crea bug y revisa los que se han rechazado y Committed, donde verifica las correcciones.

En cambio el desarrollador solo se centra en la columna New, donde espera nuevos bugs o le llegan bugs reabiertos. También puede mirar la columna approved para ver que bug están siendo corregidos.

 

Bug automáticos

Algunos de los bugs que se generarán en new, serán autogenerados por el sistema de integración continua de VSTS. Me refiero sobre todo a los bugs por rotura de build.

Debemos configurar VSTS para que después de un merge contra la rama develop, y una generación de una build, si esta falla, generara un bug critico automáticamente. Podemos configurar esto en la propia build.

autobug

Otra opción es no poder hacer merge contra develop, si la build no compila, esto haría que nunca se generara un bug critico de rotura de build, pero sobrecarga el servidor de integración continua. No poder hacer merge si no compila lo veo más para master. En develop la gente puede romper la build sin sufrir consecuencias y aprender a ser más disciplinados y cuidadosos con lo que subimos.

 

Kenny Reyes