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.


8 comentarios:

Improbable dijo...

Lindo resumen.

Algunos comentarios:

1. Si el concepto es que alguien 'pierde tiempo' testeando o ayudando al test algo huele muy mal. Más o menos como si perdiera tiempo ayudando a otro a programar o a resolver un problema técnico. Definitivamente, los programadores no pierden el tiempo trabajando en parejas con el tester, así como no pierden el tiempo trabajando en pareja entre ellos.

Si veo un riesgo en hacer trabajar en parejas a un ex usuario con un programador si ambos no están dispuestos a mojarse en el conocimiento del otro.


2. Los test automáticos me gustan, en java (o en c++ o en c# llegado el caso). Que los debe hacer un programador?. Sí, claro. Por otra parte creo que el costo de los test automáticos empieza a doler cuando la relación cambio/ no cambio en la aplicación es alta. Por ejemplo, aunque cambie catorce procesos, si mi aplicación tiene 300 y *tengo una alta reusabilidad de componentes* tal vez amerite tener test automáticos para asegurarme de que no haya roto lo que no debería cambiar.

Juan Gabardini dijo...

Hola Improbable. Gracias por los comentarios.
Comentario 1 Estoy de acuerdo!
Con respecto al riesgo, totalmente de acuerdo. Debe haber empatía, deseo de comunicarse, lo cual implica llegar a un vocabulario común. Entiendo que es la idea atrás de Design Driven-development.
Comentario 2 mmmm, no. Creo que los test automáticos deben ser una preocupación del equipo. Los programadores tienen más injerencia sobre al herramientas, pero sobre los casos no
(Asumiendo la existencia de roles como programador y tester, y asumiendo que estamos hablando de todo tipo de pruebas, no solo unitarias)
Y no te entiendo en cuanto al costo de los test automáticos. Salvo contadas ocasiones (ahora recuerdo que en la sesión de Deuda Técnica surgió el caso de sitios de promoción 'descartables'), debería ser norma automatizar las pruebas. Uno tendría que justificar por que NO usar pruebas automatizas. Pero sé que es sólo una expresión de deseos mía. La mayoría de los equipos que conozco no están en ese estado mental.

Improbable dijo...

Comentario 1: De acuerdo.

Centrémosnos en el 2. Entendí que estabas en contra de los casos de test automáticos. Entendí como la mierda, pero diré en mi defensa que... no puedo decir nada en mi defensa. Te entendí mal.

Acepto el comentario sobre quien debe hacer los tests.

Ahora, si no te entendí mal de nuevo, no te gustan las herramientas de Record&Play. Yo sí les encuentro utilidad: obviamente, el caso de test no está ni remotamente listo luego del record, pero, particularmente en amientes web, el record te da una buena base para comenzar a desarrollar el test. Has usado Selenium?. A mí me gusta su record, que te genera una cáscara (no es más que eso) que te permite comenzar a desarrollar el test.

Con respecto a quien los tiene que hacer, los test automáticos son mejores conforme el que los hace tiene más idea de programación, en mi opinión.

Juan Gabardini dijo...

De nuevo de acuerdo. No estoy usando Selenium laboralmente. Pero cuando evalué herramientas para prueba GUI, estaba tentado en ir a Abbot/Costello, por que se programa en Java (mismo lenguaje que la aplicación). Sin embargo lo descarté porque parece que la funcionalidad de Record es totalmente separada del uso de scripts, genera un archivo XML. Elegí en cambio Marathon, que si bien usa otro lenguaje (Ruby o Python), el Record genera un script que luego puede ser modificado para hacerlo más robusto.

Improbable dijo...

Selenium (no sabría decirte desde que versión) genera en record&play un html que él mismo te puede traducir a Java o C# (puede que también PHP o Ruby, pero no estoy seguro porque no uso esos lenguajes).

Yo genero las cáscaras en java con selenium y eso me sirve para saber como se invoca lo que quiero invocar. A partir de ahí construyo el test.

Santi dijo...

Juan, te recomiendo que le des una mirada a Selenium. Genera código en varios lenguajes (Java, C#, Python, PHP, Ruby y algunos más) por lo que siempre vas a tener los tests en el lenguaje de la aplicación.
El esqueleto de los tests se hace con el Record&Play y luego solo tener que exportarlo y agregar la parte interesante (parametrización, control de flujos, etc).
Yo lo uso mucho y realmente vale la pena (teniendo en cuenta que es OpenSource y su uso tiene costo 0).

Juan Gabardini dijo...

Improbable y Santi: Gracias por los comentarios. Me faltó dar información. La aplicación que estoy probando tiene GUI hecha en java (swing, no Web). Por eso no uso (ni evalué) Selenium.
Los dos productos que evalué (Abbot y Marathon) son FLOSS.

Gustavo Terrera dijo...

Estimados, trabajo como Tester Funcional aplicando metodología y acompañando a los programadores con los cuales hay un buen feed-back entre ambos. Cierto es que a veces no es un "jardín de rosas" porque hay discusiones, pero haciendo un balance, el intercambio es bueno. Yo aporte el conocimiento funcional, de reglas de negocio y de metodología para testear y para el aseguramiento de la calidad. Saludos, Gustavo (http://www.testingsoftware.com.ar)