Definición de estrategias de pruebas colaborativas
Publicado por Agustin Mariano Joison el
A modo de introducción debo comenzar dirigiéndome al lector con una serie de preguntas:
¿Qué es lo primero que piensan cuando alguien nos solicita una estrategia de pruebas?
Si me lo preguntan a mí, mi respuesta sería: dedicar varias horas (incluso días) escribiendo un documento de muchas (¡muchas!) páginas en el que se describe un proceso formal, guiado y muy detallado de cómo administrar y ejecutar un proyecto desde el punto de vista de la calidad, que luego será presentado y almacenado en algún sistema documental. Muchas veces será una tarea solitaria y repetitiva.
¿Se han preguntado o experimentado qué sucede si luego de todo este trabajo nos enteramos de que hay algo que no hemos entendido con claridad o, quizás, algún integrante del equipo poseía información valiosa, pero que solo fue identificada al observar la estrategia de pruebas?
La respuesta es retrabajo o, muchas veces, comenzar nuevamente la labor desde cero.
¿Son la definición y la ejecución de pruebas totalmente responsabilidad del QA?
¡Sabemos que no! Desarrolladores, analistas, arquitectos realizan pruebas y validaciones como parte de sus tareas diarias. Nuestro rol como QA es focalizarnos en asegurar la calidad del proyecto y guiar al equipo en sus buenas prácticas, pero el desarrollo, ejecución y reporte de las pruebas es esfuerzo de todo el equipo.
Si decimos que trabajamos bajo las prácticas de Agile, ¿por qué la definición de estrategias de calidad y planes de pruebas no puede ser como cualquier otra ceremonia (como refinamientos y planeamientos de sprint) donde todo el equipo participe?
Esta es mi propuesta: ¡definamos nuestra estrategia de pruebas colaborativamente!
El objetivo de este artículo es describir la posible dinámica de esta ceremonia donde todo el equipo sea responsable y entienda las necesidades y tareas para el aseguramiento de la calidad a lo largo del ciclo de vida del desarrollo de cada proyecto.
Cabe resaltar que no estamos buscando reemplazar la escritura de nuestro documento formal del plan y estrategia de pruebas, sino que estamos definiéndola en forma ágil para evitar retrabajos y riesgos por falta de comunicación. Luego, tendremos que describir los resultados bajo dicho documento al ser nuestra guía de implementación y también deberemos revisarlo y actualizarlo cuando sea necesario.
Diseñé una ceremonia de una hora, pero no quiere decir que se haga una sola vez, sino varias iteraciones, ya que se espera que, como resultado de este ejercicio, se originen preguntas técnicas y/o de negocio que deben analizarse y responder con tiempo.
La ceremonia constará de 6 actividades:
1.¿Qué vamos a construir?
Antes de poder definir el plan y la estrategia de pruebas, el equipo debe tener una visión clara del producto que se construirá. Aquí pediremos especial apoyo a Analistas de Negocio y Arquitectos de Aplicación que puedan describir a alto nivel el alcance y tecnología que se empleará como parte de la solución del proyecto. Sería recomendable presentar un diagrama de arquitectura y flujo de negocio principales.
Una práctica muy utilizada para resumir el alcance del proyecto desde el punto de vista de negocio es usar las técnicas conocidas como Story Mapping. Dejo el enlace para futura lectura, pero es recomendable que esto se haya hecho previamente y solo mostrar el resultado final a modo de recordatorio y en forma resumida. Del mismo modo, una técnica interesante para describir la arquitectura de las aplicaciones es seguir el modelo C4. Recomiendo que, dado el tiempo disponible para esta actividad, se analice hasta un nivel C3.
Tiempo recomendado: 10 minutos
2.¿Qué tipos de pruebas conocemos?
Es hora de poner manos a la obra a todo el equipo. Reparta notas o post-it a cada integrante del equipo e invítelos a que anoten y compartan qué tipos de pruebas conocen, ya sea que las hayan implementado o no. Coloquen los post-it sobre una pared o pizarra, agrupando aquellos repetidos y aclare al grupo las características de aquellos tipos de pruebas que no son conocidas por todos.
Tiempo recomendado: 10 minutos
3.Situar nuestras pruebas en contexto
Es posible que algunos integrantes del equipo no estén familiarizados con los procesos de calidad y les resulte difícil identificar por qué todas estas pruebas son importantes. Es aquí donde podemos hacer uso de los famosos cuadrantes de Marick o Agile Testing Quadrants.
Primero defina rápidamente el objetivo de analizar las pruebas con dichos cuadrantes (dejo adjunto el enlace al blog original que describe claramente los conceptos para que pueda explicarlos al grupo). Luego inste al equipo a tomar sus post-it y colocar cada uno en el cuadrante correspondiente. Permita que puedan equivocarse y discutir entre ellos durante unos minutos para luego realizar las correcciones correspondientes, explicando en cada caso el por qué.
Tiempo recomendado: 10 minutos
4.Descubriendo el alcance y cobertura de las pruebas
Vuelva a presentar el diagrama de arquitectura provisto por su arquitecto y pida al equipo que coloque sus post-it sobre los artefactos y componentes de dicho diagrama, buscando identificar cuáles serán las pruebas por desarrollar y ejecutar sobre cada uno de ellos. Duplique los post-it en el caso de que un tipo de prueba sea asociado a varios artefactos o a las relaciones entre ellos.
Aquí tendremos una vista y una primera estimación de la complejidad que tendrá la estrategia de pruebas y su alcance. Con ello también identificaremos posibles vacíos en la cobertura de pruebas, como así también riesgos y presupuestos. Anote cada una de estas conclusiones en post-its para ser analizados y documentadas.
Tiempo recomendado: 10 minutos
5.¿Cómo, cuándo, dónde?
Luego de definir una foto del alcance y la cobertura de nuestras pruebas, es hora de determinar cómo se distribuirán a lo largo del ciclo de vida del desarrollo. Es esperable que cada proyecto tenga su propia configuración y duración, pero aquí usaré terminologías asociadas a los procesos ágiles de desarrollo, donde el proceso, desde el punto de vista de la calidad, puede describirse como:
Nuevamente solicite al equipo que coloque los post-it con los diferentes tipos de prueba en cada una de las columnas correspondientes, haga correcciones y analice los resultados. Aquí tendremos una clara visión del momento en el tiempo en que las pruebas deberán ser desarrollados y ejecutados
Tiempo recomendado: 10 minutos
6.Herramientas de soporte
En esta última actividad vamos a definir con qué herramientas trabajaremos para desarrollar y ejecutar cada tipo de prueba. Es un buen momento para identificar cuáles serán cubiertas mediante técnicas y frameworks de automatización de pruebas. Mi recomendación: ¡automatice todo lo que pueda! Las ventajas y bondades de las prácticas de automatización de pruebas es un amplio tópico que podemos abordar más adelante, pero en los procesos modernos de desarrollo, dichas prácticas ya no pueden dejarse en segundo plano si queremos obtener productos que puedan ser entregados rápidamente a los clientes con la máxima calidad posible.
En este caso vamos a colocar primero los tipos de pruebas seleccionados como parte de nuestro proyecto en la pizarra y luego dejar que el equipo escriba en post-it las herramientas y frameworks que conocen y que ayudan a desarrollar y ejecutar cada tipo de pruebas.
Tiempo recomendado: 10 minutos
Concluión
En total fueron unos 60 extenuantes minutos, pero según mi experiencia, el grado de entendimiento y análisis de negocio, arquitectura y calidad que ha alcanzado el equipo equivale, créanme, a semanas de análisis de cada rol por separado. También brinda al equipo un sentimiento de unidad desde la génesis del proyecto, construyendo las bases de un proceso de desarrollo sinérgico y eficiente.
Enlaces de interés
Exploration Through Example - Brian Marick: http://www.exampler.com/old-blog/2003/08/21.1.html#agile-testing-project-1
A Guide to User Story Mapping: Templates and Examples (How to Map User Stories) - Jory MacKay: https://plan.io/blog/user-story-mapping/#:~:text=Breaks%20down%20epics%20into%20manageable,down%20larger%20stories%20or%20epics
C4 Model - Simon Brown: https://c4model.com/