Retrospectiva de la Estrategia de Pruebas

Estoy leyendo el libro de Katrina Clokie “A Practical Guide to Testing in DevOps”, y una de las tantas cosas que me vienen gustando del libro, son las distintas dinámicas que plantean para generar conversaciones sobre las tareas de desarrollo y calidad. En particular acá te resumo una dinámica llamada “test strategy retrospective” (retrospectiva de la estrategia de pruebas) en la que se analiza cómo se viene realizando el testing, buscando alinear al equipo y generar un plan de acción para mejorar las tareas de calidad.

Dinámica para una Retrospectiva de la Estrategia de Pruebas

El objetivo es alinear al equipo en la estrategia de pruebas, viendo que todos sepan cuál es la estrategia, y estando de acuerdo en qué aspectos de la estrategia se están implementando y cuáles no.

El tema es que incluso teniendo la estrategia de pruebas documentada, cada integrante del equipo puede tener distintas cosas en mente sobre qué tareas de calidad se realizan, o se deberían realizar. En este sentido es que se marca la importancia que esta tarea no es para testers, es para todo el equipo (scrum o no scrum, esto es aplicable a diversos contextos).

Preparación

Se necesita un facilitador, que puede ser por ejemplo, el tester del equipo. Podría ser el Scrum master supongo, pero lo bueno de que sea el tester es que este no va a participar en la dinámica, evitando cierto sesgo que podría ocurrir.

Este necesita conseguir:

• Una hora con el equipo disponible.
• Sticky notes de 4 colores distintos.
• Una pared o papelógrafo donde pegar sticky notes.

Creación de la Visualización

Hay que comenzar la retrospectiva aclarando que el objetivo es alinearnos en cuanto a la estrategia de pruebas y cómo el equipo la entiende, lo que consideran todos que está sucediendo al respecto.

En la pared poner dos sticky notes de un color, una bien a la izquierda que diga “Idea” y otra bien a la derecha que diga “Production”. De esta forma la pared representa como una línea de tiempo desde que aparece una idea hasta que esta se pone en producción.

Entonces, los otros tres colores se usarán para lo siguiente:

• Violeta: tareas de calidad que están en la estrategia y las estamos haciendo.
• Rosado: están en la estrategia y no las estamos haciendo.
• Amarillo: no están en la estrategia y las deberíamos hacer.

Cada participante debería poner sticky notes en la línea de tiempo donde ellos creen que esa tarea debería estar ocurriendo de acuerdo a la estrategia, considerando los colores como se mencionó antes. Se puede dejar una ventana de entre 5 y 10 minutos, según la cantidad de participantes y las ideas que vayan surgiendo.

Luego, tomar otros pocos minutos para pedirles a los participantes que trabajen entre todos para agrupar las sticky notes, ya que seguramente habrán muchas tareas repetidas o similares, o podrán haberse ido colocando a destiempo entonces requiera una reorganización.

Cuando todos están de acuerdo, se hace la puesta en común.

Discusión

Hay algunas preguntas para hacer acá:

• ¿Hay grupos con distintos colores? ¿por qué?
• ¿Hay distintos nombres utilizados para las mismas cosas? ¿por qué?
• ¿Qué tareas faltan de las que están en la estrategia de pruebas? (el tester debería aportar en esto)
• ¿Qué tareas faltan en la estrategia? ¿no las queremos incluir?

Estas preguntas pueden llevar a descubrir malos entendidos. También pueden llevar a compartir el por qué de ciertas decisiones sobre la estrategia de pruebas, aportando en la transparencia, lo cual es uno de los pilares de Scrum. Se pueden dar situaciones de que la misma tarea sea nombrada de distintas formas, y sea bueno llegar a un consenso.

Un ejemplo que nombra Katrina que me parece claro, es que si por ejemplo varios nombraron el test unitario en una sticky note violeta, mientras un desarrollador la puso en una rosada o amarilla, puede mostrar puntos en los que no estamos alineados o informados sobre lo que estamos haciendo o deberíamos estar haciendo. Lo importante es generar conversaciones y de ahí definir un plan de acción.

Puesta en Práctica

En Abstracta lo pusimos en práctica a modo de enseñanza, ya que el equipo que participó era bien heterogéneo y no están participando de los mismos proyectos. De todos modos, la dinámica fue bien interesante como para discutir sobre las distintas tareas a agregar a una estrategia de pruebas, cuándo ejecutarlas, etc.

 

Claramente usamos otros colores 🙂

Taller de Técnicas para Testing Ágil (Abstracta + Peregrinus)

Con Gabriel Montero de Peregrinus estamos preparando un Taller de testing ágil, que será el 13 y 14 de diciembre (de 9 a 13 hs), donde intentamos combinar nuestras áreas de trabajo y experiencia: testing y metodologías ágiles. Es un tema que en los testers genera mucha incertidumbre: ¿qué hay que saber, aprender, adaptar? El testing es una parte fundamental en las metodologías ágiles y se habla de que todos son responsables de la calidad, y eso ha llevado a hablar del tema que el rol del tester está muriendo.

Para nosotros el tester pasa a tener un rol más relevante, pero tiene que adaptar su forma de trabajo que trae de las metodologías tradicionales y eso es lo que queremos motivar a la gente a pensar, brindar herramientas y tácticas para poder brindar el mayor valor de su rol a los equipos que trabajan en estos esquemas de trabajo.

Escribir un buen criterio de aceptación requiere un skillset de tester, pensar en características de calidad, testeabilidad, mantenibilidad asociado a deuda técnica, etc., hacen que sea fundamental aún el rol del tester.

El curso demás no lo estamos pensando solo para testers, sino que apuntamos a las tareas de testing y calidad, y si consideramos el concepto de T-shaped skills, todo participante de un equipo ágil debería tomar este curso.

Si te interesa, contactate o mirá más info acá.