En una gran cantidad de proyectos en los que se desarrollan y mantienen productos digitales, a pesar de estar gestionados mediante metodologías ágiles, usando marcos como Scrum o Scrumban, y teniendo equipos integrados por Product Owners, Scrum Masters, Developers y Testers ágiles (manuales y automatizadores), pasa algo muy común.
Las herramientas que te ofrecen tener la visión global (big picture) del valor y la experiencia del cliente, onda el «Customer Journey Maps» y el «User Story Mapping», se quedan, por lo general, en manos del Product Owner (y a veces el Scrum Master le da una mano). El Test Lead y/o el equipo de testers no suelen ser parte activa de la creación o el uso directo de esos mapas.
¿Por qué pasa esto? Posiblemente por costumbre, porque el testing viene «de otro palo», o quizás no se ve claro cómo esos mapas son oro puro para probar mejor, y aquí un punto. La expresión «probar mejor» no refiere únicamente a los testers sino a todos los miembros del equipo (completo), tal y como la práctica ágil recomienda.
La cuestión es que la información clave que sale de ahí (ese entendimiento profundo del usuario y sus problemas/necesidades) viaja del PO/SM hacia el resto del equipo, incluidos los testers, pero ya como requisitos traducidos a Épicas y/o Historias de Usuario o tareas digeridas, y a veces, ni siquiera masticadas (¿se entiende verdad?).
Obviamente, esto tiene su impacto. El no tener contacto directo con los mapas, el Test Lead y/o Equipo de testers puede perderse de matices importantes del flujo real del usuario o de los puntos de dolor del cliente que no quedan del todo explícitos en una User Story suelta. Y claro, esta dinámica moldea cómo se encaran las cosas los diferentes artefactos y ceremonias que se dan en todo Sprint.
El testing participa, sí, pero a menudo partiendo de una base que ya les llegó «procesada» (…a veces no del todo) en lugar de ser co-creadores o miembros participantes directos de esa visión estratégica.
El foco del presente estudio va por esta dirección, tratando de responderme las siguientes preguntas:
- ¿De qué manera herramientas como «Customer Journey Maps» y «User Story Mapping» ayudan y facilitan el trabajo del Tester en su proceso de testing?
- ¿Cuál es el conocimiento previo que debe adquirir un Tester para entender en qué momento y cómo utilizar estas herramientas no sólo para su beneficio sino para el beneficio de todo el equipo de proyecto y por ende, del cliente?
- ¿Cómo lograr que un equipo de proyecto logre la madurez necesaria de incorporar la figura del Tester durante las primeras instancias del uso de estas herramientas?
- ¿Cómo ir intercalando el uso de estas herramientas con las actividades habituales del Test Lead y/o Equipo de Testes en ausencia del rol de líder?
- ¿Cómo fijar las reglas de uso de estas herramientas entre los roles de PO, SM y Test Lead?
- ¿Cuánto impacta al rol del Test Lead la interacción y uso de estas herramientas en el momento de estimar el testing durante la Sprint Planning?
- ¿Cómo hacer que el PO comprenda la importancia de hacer participar al Test Lead en el CJM y USM.
Seguramente habrá otras preguntas que nos podamos plantear, por el momento las que expongo son las que se me ocurrieron.
Básicamente el foco principal está en identificar situaciones específicas en un Sprint donde estas herramientas son útiles para un Test Lead, durante la planificación del Sprint, el refinamiento del backlog (previo al Sprint) y la ejecución del Sprint, ya que son artefactos de referencia vivos dentro de cada Sprint, proporcionándole:
- el contexto necesario para comprender el valor que se está desarrollando;
- identificar el alcance adecuado de las pruebas;
- descubrir riesgos potenciales (funcionales, no funcionales, de experiencia);
- diseñar casos de prueba más efectivos;
- y en última instancia, contribuir a la entrega de un incremento de producto de alta calidad que realmente esté alineado con las necesidades planteadas y mejora la experiencia del cliente.
Estas herramientas son de uso común en muchos proyectos ágiles por parte del PO y/o SM, y de hecho hay templates que se pueden reutilizar como los que se encuentran en «miro» o en «asana» por darte dos ejemplos.
Ahora bien, ¿La Inteligencia Artificial Generativa en qué nos puede ayudar? y aquí si, la respuesta cobra otro color y otras dimensiones.
De acuerdo a lo que vengo investigando y específicamente con este tema, hay mucho por explorar y que también te compartiré algo de todo lo que he podido analizar:
- Generación y expansión de casos y escenarios de prueba.
- Generación de datos de prueba.
- Resumen y extracción de información relevante para nuestro testing.
- Identificación proactiva de posibles problemas y riesgos.
- Refinamiento de los criterios de aceptación a pasos de prueba ejecutables.
- Identificación de aspectos relacionados con la seguridad de datos y aplicaciones.
En la próxima publicación, comenzaré a profundizar en cada una de las áreas de conocimiento planteadas.
Comentario final: Sígueme por LinkedIn si prefieres.
