Cómo gestionar tareas de Agile Testing con JIRA y sin plugins

JIRA es una gran herramienta para proyectos en SCRUM. Pero… ¿como encajamos las tareas de Agile Testing en las historias de usuario en JIRA? Te explicaré como gestionar estas tareas de un modo sencillo, y sin necesidad de plugins adicionales, con JIRA.

Antes de empezar hay que destacar una premisa fundamental de agile testing: Una historia de usuario no está terminada si no está probada. Esto, que parece obvio, tiene una implicación importante: desarrollo y test son tareas que van de la mano. No esperas al final para empezar a testear la historia.

En resumidas cuentas el agile tester participa en todo el ciclo de vida de una historia de usuario,  y tiene entre otras funciones:

• Validar que una historia tenga definidos criterios de aceptación.
• Examinar la testabilidad de las historias de usuario.
• Análisis de riesgos de la historias de usuario.
• Identificar aspectos funcionales y no funcionales del sistema a testear.
• Definir los niveles de tests necesarios.
• Desglosar las tareas de test de las historias de usuario.
• Estimar el esfuerzo para las tareas de tests.
• Ejecutar las tareas de testing
• Verificar que se cumplen los criterios de aceptación
• etc..

¿Es posible hacer todo esto en JIRA sin plugins de terceros? Pues sí.

Vamos con un ejemplo:

Para seguir este ejemplo, créate en JIRA un proyecto de prueba  y asegúrate que sea de tipo «Scrum software development».

Scrum software development – JIRA

Supongamos que tenemos un e-commerce y en el formulario de clientes queremos añadir un checkbox para indicar si el cliente es un particular o una empresa.

La historia de usuario es:

• Como cliente quiero poder seleccionar qué tipo de cliente soy para que esa información se refleje en mi ficha de cliente

Crea la historia de usuario:

Historia de Usuario – JIRA

Pásala del backlog al sprint:

Backlog -JIRA

Ha llegado el momento de que el equipo comience a desglosar la historia en tareas y QA ya comienza a «probar» la historia.

Lo primero que nos planteamos es si la historia tiene criterios de aceptación. Preguntamos al Product Owner y extraemos que los criterios de aceptación de este ejemplo serán:

• Que aparezca el nuevo campo «Tipo Cliente» en el formulario Clientes con los valores seleccionables «Cliente»  y «Empresa»
• Que el campo se guarda, se recupera y se puede modificar desde el formulario

Esta información la añadimos a la ficha de JIRA. Con esto ya sabemos que la historia es testeable ya que podemos comprobarlo tanto de forma manual como con un test automático de Selenium.

Historia de usuario con criterios de aceptación

Para este ejemplo nos saltaremos el análisis de riesgos ya que es una historia con casos muy sencillos. Para historias más complejas donde no da tiempo a probarlo todo, es recomendable priorizar las pruebas en función del riesgo.

Sobre los aspectos no funcionales, el product owner nos  indica que no son críticos en esta historia, así que no sería necesario probar por ejemplo el rendimiento a la hora de guardar o recuperar las fichas de cliente con este nuevo campo.

Con toda esta información nos salen dos tareas de QA:

• Queremos tener un test automático que haga una alta, baja y modificación cambiando los valores del nuevo campo «Tipo Cliente» para comprobar que se graba y recupera correctamente. Lo haremos automático y pasará a formar parte de nuestra suite de tests de regresión. Esta prueba se enmarca en el cuadrante 2 de Agile Testing.
• Además queremos comprobar como queda en el look & feel del formulario ese nuevo campo y cómo afecta a nivel de usabilidad. Programamos una sesión de testing exploratorio para comprobar esto. Estas pruebas estarían en el cuadrante 3.

Con toda esta información creamos como subtareas, las tareas de desarrollo y QA:

Vale, a trabajar. ¿Cómo gestionamos las tareas?

En el ejemplo, iniciamos el sprint y DevNinja y SamuraiQA comienzan a trabajar juntos en la historia. La historia se pone «En progreso» y las tareas 1 y 3 también.

Progreso de las tareas – JIRA

Cuando las tareas de desarrollo ya están finalizadas se puede hacer la tarea 4 (testing exploratorio).

Progreso de las tareas – JIRA

Pero resulta que durante la sesión de testing exploratorio, SamuraiQA encuentra un bug : el campo «Tipo Cliente» no está bien alineado en el formulario. Vamos, un desastre a nivel visual. Lo que hacemos es relacionar el bug con la historia indicando que la bloquea.

Historia con bug que la bloquea -JIRA

DevNinja arregla el bug y una vez SamuraiQA lo ha verificado, todas las tareas y bugs relacionados que bloquean la historia están hechos.

Historia finalizada – JIRA

Ahora ya sí, la historia está terminada.

Posibles mejoras

Este modelo de gestión es bastante sencillo y funciona con los proyectos SCRUM «de serie» en JIRA. Pero en tu proyecto quizá necesites un detalle más fino o más visisibilidad. Te propongo dos mejoras (sin plugins) que puedes implantar de manera sencilla:

• Distinguir las subtareas de QA  de las de desarrollo: clona el tipo subtarea y create una para QA y otra apara desarrollo, por ejemplo: QA SubTask y Dev SubTask
• Añadir estados en el workflow. Por ejemplo, si necesitas saber si una historia tiene criterios de aceptación, si ya están sus tareas desglosadas, o está lista para pasar a producción, puedes añadir estados al workflow como «Analizada», «Desglosada», «Lista para producción», etc…

Si te ha parecido útil o se te ocurren mejoras, no te cortes y deja un comentario 🙂