Dinámica basada en Agile Testing Quadrants

Como parte del curso de Testing en Agile Context que hemos brindado en Abstracta en los últimos años, diseñamos una dinámica basada en los agile testing quadrants que Lisa Crispin adaptó de la versión original de Brian Marick.

Historia de cómo diseñamos la dinámica

Un input fundamental para esto fue una conversación que tuve con Katrina Clokie ya que ella lo nombra en el libro “Testing in Devops”. Katrina indicó que no usa tanto los cuadrantes, pero la utilidad es principalmente para generar conversaciones sobre la estrategia. La idea principal es ver que en la estrategia de pruebas haya un balance, tanto de las actividades que hay arriba y abajo, como izquierda y derecha. Con respecto a izquierda vs derecha, la diferencia está en probar que el software funciona vs buscar lo que no funciona o lo que puede salir mal.

Las nubes de las esquinas no son útiles para ella, incluso para mí agregan alguna contradicción, como por ejemplo al querer ubicar la actividad de “code review”, ya que es una actividad con foco tecnológico (abajo) y que da soporte al equipo (izquierda), pero el cuadrante Q1 indica que eso debería incluir tareas automatizadas, y el code review no es automatizado.

Otro agregado que le hicimos a la actividad, fue a partir de lo que aprendí asistiendo a un taller de Lisa Crispin y Janet Gregory en Agile Testing Days en USA. Una visión que no había tenido relacionada al cuadrante, es que se puede pensar todo el lado izquierdo como las pruebas que se hacen antes de tener al producto para probar y las que están a la derecha como las pruebas que se hacen luego de tener el producto terminado. Entonces, con el fin de pensar más en actividades de testing más tempranas en el proceso de desarrollo, nos forzaron a utilizar solo la parte izquierda del cuadrante.

Claro está que luego de varias iteraciones poniendo en práctica la dinámica, a veces solo, a veces junto al equipo de Abstracta y varias veces con mi gran amigo Gabriel Montero, la dinámica se fue enriqueciendo y aquí te la comparto.

Dinámica

La idea básicamente es poner el tablero de los cuadrantes en un papelógrafo en una pared o en una pizarra, donde ahí se irán posteando las ideas por parte de los participantes del equipo.

Luego de mostrar el tablero es bien importante explicar qué significa cada una de sus partes:

• Soporte al equipo: se refiere a las actividades que dan soporte al equipo, que permiten hacer cambios con más confianza. Son pruebas que no buscan algo nuevo, sino que buscan validar algo que ya se conoce (generalmente todas las pruebas de regresión). 
• Crítica al producto: son las pruebas que se ejecutan sobre un producto para encontrar errores. Se buscan cosas que no se conocen.  
• Vistas a la tecnología: estas son las pruebas con vistas a la tecnología, que generalmente los resultados van a ser de interés para el técnico, el desarrollador, el arquitecto. 
• Vistas al negocio: acá entran las pruebas que tienen foco en el negocio, podrían pensarse como las pruebas que dan resultados que un Product Owner (o Project Manager) estará interesado en escuchar, que podrá entender. 

Algo importante, esto no es una categorización de tareas de testing, ni una taxonomía. La utilidad es principalmente para generar conversaciones sobre la estrategia. La idea principal es ver que en la estrategia de pruebas haya un balance, tanto de las actividades que hay arriba y abajo, como izquierda y derecha. Vamos a ver que la actividad nos va a permitir también mejorar la visualización y entendimiento compartido que hay en el equipo.

Posteo de ideas

• Se les da un total de 8 minutos a los participantes para que piensen actividades de la estrategia de calidad, pidiendo que la escriban en postits de la siguiente forma:
  • Postit verde si se trata de una tarea que el equipo hoy SÍ realiza.
  • Postit rojo si se trata de una tarea que el equpo hoy NO realiza, pero se considera que se debería incluir en la estrategia.
• Luego que terminaron las ideas, se les da 2 minutos más para que piensen bien a qué cuadrante corresponde cada una.
  • Escribir en una esquina del postit a qué cuadrante corresponde (si en Q1, Q2, Q3 o Q4). Esto es algo importante y a su vez complejo, dado que hay que reflexionar por qué se está haciendo esa actividad, con qué fin.
• Cada persona pasa (uno a la vez):
  • Se coloca cada postit en el cuadrante indicado explicando brevemente a qué se refiere, agrupando con postits puestos anteriormente de ser posible.
  • Debería explicar por qué coloca la actividad en ese cuadrante (justificando por que le da soporte al equipo o si es para criticar el producto, o por qué tiene vistas de negocio o tecnológica). 

Reflexiones

Luego de tener todos los postits en la pizarra se puede comenzar a discutir, prestando atención a algunas cosas que dan pie a la reflexión, como por ejemplo:

• ¿Hay cuadrantes menos poblados? ¿Por qué sucede esto?
• ¿Se usan nombres distintos para describir a las mismas actividades?
• ¿Hay personas que creen que ciertas cosas se están haciendo y otras creen que no? O sea, ¿aparecen las mismas actividades pero en colores diferentes?
• ¿Aparecen las mismas actividades pero en cuadrantes diferentes? ¿Por qué? ¿Hay personas que las ven útiles para algunas cosas y otros las ven con otra utilidad?

Quizá te estés preguntando ¿qué tiene que ver esto con la estrategia y planificación de pruebas? ¿Deberíamos cubrir cada cuadrante? ¿Qué hacemos con las diferencias, cómo saber quién está en lo cierto?

Esto es una herramienta, no es una regla. Tampoco es una taxonomía ni clasificación. Es una herramienta para hacernos preguntas y para generar discusión, para dar visibilidad y para compartir puntos de vista, necesidades, opiniones sobre cómo debería ser la estrategia de calidad.

Es interesante destacar también, que puede ser que una actividad que hoy sirve de soporte al equipo quizá evolucione en el tiempo y luego pase a cumplir otra función, que se mueva de cuadrante. Lo importante es que las distintas personas estén alineadas en por qué se hace cada actividad. 

Como se ve en esta imagen, luego de terminar la actividad (y otras veces antes…) agrego también la aclaración que lo que está a la izquierda se relaciona más con las actividades que se hacen antes de tener el código y lo que está a la derecha generalmente se hacen después, así como también lo que está arriba es para “construir el producto correcto” y lo que está abajo está más relacionado a “construir el producto correctamente”.

Cerrando

Me encantaría conocer historias de cómo te va poniendo en práctica esta actividad en tu equipo. En mi caso, las veces que la he puesto en práctica, ya sea en equipos o en cursos (donde hay personas de diferentes empresas) el aprendizaje que se obtiene es súper enriquecedor.