Una iteración en la vida del Tester

Con la llegada de las metodologías ágiles, el rol del Tester sufrió una transformación. Una de las principales diferencias con otras metodologías es el ritmo de las tareas de testing, que se expanden a lo largo de cada uno de los ciclos de desarrollo ágil, llamados iteraciones.

iteracion tester

Cómo son, día por día, las tareas del Tester durante cada una de esas iteraciones?

Día 1: En el primer día de cada iteración, las user stories de más alta prioridad se van tomando del backlog. El Tester, junto con el resto del equipo y el Product Owner, deberán trabajar en definir los criterios de aceptación para cada una de esas user stories. Es el momento de formular las preguntas de más alto nivel, para ir delineando la funcionalidad que entregará cada una de las user stories, como así también cuál va a ser el valor que le aportará al negocio.

Durante la segunda parte de la sesión de planificación, deberán identificarse y estimarse las tareas de testing para cada una de las stories. Típicamente, las tareas de testing son: “Definir casos de prueba”, “Escribir tests automatizados”, “Ejecutar prueba exploratoria”.

Días 2 y 3: En estos días, la principal tarea del Tester consiste en mantener conversaciones con el Product Owner, con el objetivo de refinar los criterios de aceptación para cada una de las user stories. La buena comunicación es clave en esta etapa, porque le permitirá al Tester dilucidar en detalle qué es lo que se espera de cada una de las funcionalidades. Este es un proceso que bien puede continuar en los días subsiguientes.

Asimismo, durante estos días, el Tester comenzará a diseñar los tests de aceptación. Esto debe verse como una tarea colaborativa, que ayudará a guiar el desarrollo, en la medida en que los desarrolladores escriban el código que pase esos tests. Esta tarea de escribir tests de aceptación continuará durante los siguientes días. Normalmente, el proceso de diseñar estos tests disparará nuevas preguntas, que generarán nuevas charlas con el Product Owner, a fin de continuar refinando los criterios de aceptación.

Días 4 y 5: Aquí es donde suele comenzar el test exploratorio, ya que normalmente ha finalizado el desarrollo de algunas de las user stories. Entonces, una vez que se ha asegurado de que los tests del “camino correcto” pasan, el Tester comienza a usar su creatividad para pensar en condiciones o escenarios en los que nadie pensó, y de esa forma encontrar errores inesperados. Generalmente, se seguirán ejecutando pruebas exploratorias hasta casi el final de la iteración.

Días 6 y 7: En la medida en que se van desarrollando más user stories, el Tester comienza a ejecutar pruebas que buscan verificar funcionalidades combinadas o integradas. El objetivo es asegurarse de que las nuevas funcionalidades se integran correctamente con las funcionalidades pre-existentes. Esta tarea seguirá adelante por un par de días por lo menos. El éxito de esta tarea depende en gran medida de que las user stories estén diseñadas correctamente

Días 8 y 9: Asumiendo que el desarrollo de todas las user stories está completo hacia el 8vo. ó 9no. día, es el momento de ejecutar pruebas end-to-end, que verifiquen tantos escenarios como sea posible, siempre basándonos en casos reales de uso del sistema. El principal objetivo de estas pruebas es verificar que todas las nuevas funcionalidades aumentan el valor del software para el negocio y que el mismo se halla en condiciones de ser entregado al cliente o usuario final.

Día 10: En el último día de la iteración, el equipo realiza una demostración de las user stories al Product Owner, buscando obtener su aceptación. Esta demo generalmente requiere un armado cuidadoso, como generar los datos necesarios o asegurarse de que todas las funcionalidades están listas para ser demostradas. Así, el equipo completo se concentrará en generar una versión que pueda ser presentada al cliente. El Tester, por ser quien está más familiarizado con las funcionalidades, suele ser el encargado de llevar adelante la demostración.

Asimismo, como cierre de la iteración, se suele realizar una reunión denominada retrospectiva, donde todo el equipo analiza la marcha de la iteración que está concluyendo, resaltando los aspectos positivos (que deben repetirse) y los que se pueden mejorar. El Tester aportará su visión a esa retrospectiva.

Aclaración: La duración de cada una de estas tareas no es taxativa, sino más bien indicativa, y puede variar de un proyecto a otro. Es decir, que algunas tareas podrían comenzar antes o después de lo indicado más arriba, y prolongarse por más tiempo, incluso más allá del final de la iteración.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s