¿Se puede proponer un espacio para debatir acerca de la mentalidad del equipo Agile relacionada con las pruebas como parte integral de las actividades del equipo?
¿Se entiende que por Equipo Ágil me refiero a todos sus miembros verdad? Product Owner, Scrum Master, Analista, Desarrollador, Tester. No es menor este comentario.
Equipos ágiles en donde la relación tester/desarrollador es de 1 T (+/-) 3 D ¿Es algo común verdad? ¿Cuál es la relación que existe en tu equipo ágil? ¿Estoy muy alejado de la realidad?
Más allá de que muchos pensemos si la relación es la más adecuada debiendo considerar no sólo la relación cantidad sino además el seniority (Nota: aspecto no tenido en cuenta muchas veces), miembros de nuestra comunidad de tecnología piensan que las actividades de prueba (y no de testing) deben ser realizadas principalmente por el tester del equipo, y es aquí donde se centra el foco del artículo. ¿Porqué el concepto de probar se lo asocia únicamente al tester?¿No es acaso que todos los miembros del equipo ágil deben perseguir la calidad en el desarrollo del producto?
¿Está cambiando este pensamiento? ¿En tus Tribus hay Squads que están convencidos que las pruebas deben pasar únicamente por los testers? ¿Que sucedería si todo el Squad, es decir el equipo completo, pensara en las pruebas?
Planteo de una situación («…cualquier similitud con la realidad es pura coincidencia…»):
En una reunión de planificación (Sprint Planning) cuando como equipo se estaban discutiendo funciones de una User Story para desarrollar el incremento a entregar al final del Sprint, de pronto uno de los desarrolladores le pregunta al equipo de testers: «¿Cómo van con las pruebas? En ese momento pasó por mí mente la clásica pregunta: «¿What!?»
¿Es correcta esta situación? ¿En qué habrá derivado? Te propongo pensar en dos posibles situaciones que se pudieron haber dado:
S1: El tester comunicó no solo al desarrollador que preguntó sino a todo el equipo el avance del testing, los defectos y bugs detectados e informados entendiendo que serviría para lograr reconocer y definir prioridades y estimaciones. (¿Equipo inmaduro?)
S2: Se generó una charla dónde todos compartieron sus ideas y propuestas de mejora y de mejor aplicación de la metodología scrum, establecieron acuerdos y provocaron cambios en la forma de desarrollar y testear. (¿Equipo en proceso de maduración?)
¿Y entonces qué?
El equipo ágil (en su conjunto) entendió que el concepto de «probar» es una actividad de equipo y no algo que debe hacer exclusivamente el tester.
El tiempo fué pasando de Sprint a Sprint y en las reuniones de planificación el equipo (y en las otras ceremonias) se formulaban las siguientes preguntas:
¿Cómo vamos a probarlo como equipo? ¿Cómo podemos desarrollar y probar esto para que como equipo tengamos la confianza de que funcionará una vez entregado al cliente?
En este escenario donde todo el equipo pensaba en las pruebas, los desarrolladores diseñaban y registraban sus pruebas unitarias, además de apoyar en todas las necesidades para el resto del testing, preparando arneses, stubs, scripts automatizados, documentación más clara, queries que permitían reducir tiempos, y otras cuestiones.
Los testers por su parte aportaban su visión para que los desarrolladores pudieran entender otros aspectos del alcance de los diferentes criterios de aceptación de cada historia de usuario para enriquecer aún más sus pruebas unitarias / funcionales.
El PO aportaba desde su visión, nuevos escenarios que entendía que podían representar muy buenos candidatos a ser probados.
De esta forma, un cierto porcentaje de los defectos que se detectaban correspondían a escenarios complejos relacionados con determinadas reglas de negocio que no se habían considerado.
Tal vez te preguntes aquí ¿Que otro tipo de sinergia se originaba en el equipo?
Aquí es donde todo agile testers puede mostrar sus habilidades:
- el conocimiento general del sistema o de gran parte de éste y que contribuye en las diferentes fases del desarrollo de software.
- pensar respecto del producto desde el punto de vista del usuario final.
Estas dos habilidades se podían aplicar durante las primeras fases del desarrollo, y así el mayor esfuerzo dedicado al principio implicaba menor esfuerzo al final del Sprint, levantando menor cantidad de defectos y/o identificar defectos complejos.
El resultado de trabajar bajo este enfoque dió lugar a generar mayor confianza entre todos.
Confianza, concepto que con mucho trabajo de comunicación y dinámicas disruptivas, permite lograr la conformación del EQUIPO.
Conclusión
El modelo de equipo completo donde todos piensan en las pruebas es el que debe estar aplicandose de ahora en más (vaya a saber en cuanto tiempo éste se verá modificado por otro mejorado) para ir cambiando (y rápidamente por la velocidad del negocio) la mentalidad de todos los miembros del equipo así como también de ciertos testers que se encuentran trabajando en marcos ágiles y actuando como agile testers, y donde muchos de ellos vienen de marcos tradicionales.
El agile developer deberá pensar, y porqué no estudiar, para cambiar el mindset y así comprender que además de contar con habilidades de programación debe reconocer a las pruebas como parte integral en el desarrollo de todo producto de software.
Por otra parte, el agile tester deberá saber interpretar en este contexto aquellos problemas de prueba de una cierta complejidad entendiendo que un cierto porcentaje de pruebas estarán siendo tratadas por el resto del equipo, sin que por ello implique que dejará de atender cierta parte de las mismas.
Fuente de la imagen. pixabay chenspec
