jueves, 12 de marzo de 2009

Testers en entornos ágiles

En una de las sesiones en las que participé en Agile Open Buenos Aires 2009 nos reunimos unas 15-20 personas y comentamos sobre como participan los testers en equipos ágiles.
¡Qué tema! Me apasiona, y me lo tomaba mal, hice algo para cambiar. y ahora estoy un poco más tranquilo (Dilema de los testers).
Justamente iniciamos la sesión y para abrir el juego, comenté lo que considero es el Dilema de los testers: Tenemos que trabajar y ayudar al equipo para lograr que el testing (tradicional, al final del desarrollo) ya no sea necesario.

A partir de ahí, tuvimos un intercambio de dudas, experiencias y opiniones, no necesariamente logramos consenso, pero fue muy interesante. Algunos de los ejes de la discusión fueron (ver la imagen):

Perfil de los testers
¿Tiene un tester un ambiente ágil que saber sobre tecnología?
Parece que sería bueno (en eso hay concenso) pero es necesario?
Un tester técnico se integra más fácilmente con un equipo de programadores, pueden más fácilmente tener un leguaje comun y es más factible que participe en la automatización de las pruebas. Puede aportar en las pruebas técnicas, mejora su participación en pares, ...

Selección
Todo bonito, pero ¿existen esos testers? En general vemos que los procesos de selección no los encuentran, y quizás no haya muchos. Una hipótesis es que las personas con interés en lo técnico se hacen programadores/diseñadores/arquitectos, ya que es más redituable en el mercado actual. El mercado lleva a que estos perfiles sean rara avis, ni siquiera se consideran en las clasificaciones de puestos en los anuncios, lo que dificulta que se pongan en contacto las empresas que necesitan con las personas correctas.
Algo de eso comentamos en un thread del grupo de desarrollos ágiles en español.

Homologación
No le dimos mucho tiempo, pero surgió el tema de los grupos de testing fuera del grupo de desarrollo, y como se maneja este caso. Estos grupos consisten en algunas experiencias en ex-usuarios, que conocen muy bien el negocio y el día a día, por lo que son muy buenos proxies de los usuarios reales (si se mantienen actualizados), como aprovechar ese conocimiento?

Tester como Analista/Product Owner
Una forma de aprovechar los conocientos de negocio es que los testers sean parte del equipo de P.O. o desde el equipo de desarrollo, interactuen con los P.O. para lograr que los temas de usabilidad y detalles del negocio estén en las condiciones de aceptación de las historias.

Volvemos al perfil
Si las personas con perfil de testing no son técnicos (como los casos considerados arriba), como los incorporamos para que sean más efectivos al team? Con herramientas que permitan que personas no técnicas definan casos de prueba (se comentó Quality Center y FitNesse), y la otra es que trabaje en pares con programadores. Una preocupación que surgió es que tanto FitNesse y el trabajo en pares consume tiempo de los programadores. 

Compromiso a nivel equipo
Si los progamadores "pierden tiempo" ayudando a los testers, esto huele (smell) a que falta Compromiso a nivel equipo (Whole team commitment). Si no se considera que el resultado del equipo es el producto con las pruebas que sean, cualquier tarea (prueba) u obstaculo (falta de conocimiento técnico de alguno de los miembros) es algo que el equipo completo debe resolver. No es un problema de "los testers".

Equipos con roles
Otra cara de la moneda es el uso de herramientas de automatización que hacen record& play o tienen lenguajes propietarios fáciles (VBScript). No hubo concenso. Algunos comentaron que lo usaban y les funcionaba. Otros creemos que las herramientas de record& play no pueden usarse para generar casos de prueba automatizados robustos. El costo cuando (no si) hay cambios en la aplicación es demasiado alto. Se debe ir a casos de prueba que sean resistentes a los cambios de la aplicación, y eso es dificil de lograr sin tener los casos implementados con algún tipo de lenguaje (no la salidad directa del record). El caso de los lenguajes propietarios tiene varios problemas: mayor costo de aprendizaje, aumenta el riesgo de que un problema con un miembro del equipo afecte la capacidad de finalizar, aumenta posibilidad de cuellos de botella y en general dificulta la formación del Compromiso a nivel de equipo. Sin mensionar que los lenguajes propietarios suelen ser restringidos y no facilitan que se haga código de calidad, robusto.

Impacto de no lograr el Compromiso del equipo
Si los programadores consideran que las pruebas corriendo y verdes no son su problema, pueden hacer cambios en el producto que causen que muchas pruebas se rompan, si considerar el costo de poner nuevamente en funcionamiento las pruebas. Si en cambio lo consideran algo que los afecta, se preocuparán en que las pruebas sean código de igual calidad que el resto del código del producto, para que sea más robusto, extensible, etc. Eso es bueno, ya que los testers no son los mejores preparados para lograr código de calidad. En este caso, surge naturalmente que los programadores preferirán usar las mismas herramientas para el código de prueba que para el resto del código.

Quedaron temas pendientes
¿Cómo se hace en el caso de software embebido? Buscar Nancy Van Schooenderwoert

Mi resumen
Necesitamos equipos con todos los skills. Ojalá tuvieramos miembros que entiendan del negocio y conozcan la tecnología de la solución y sepan probar y tengan en cuenta usabilidad y ...
Cada equipo es particular, por lo que hablar del "rol de tester" es sólo una abstracción... salvo que la persona que cubra ese rol sale de un mercado que tiene cierta demografía. Por lo tanto si no encontramos personas para cubrir ese rol definido como {conocimiento de técnicas de testing, conocimiento del negocio, afinidad técnica sin ser experto} podemos cambiar la definición del rol o cambiar la demografía.


Publicar un comentario en la entrada