sábado, marzo 20, 2010

La horda de testers

sábado, marzo 20, 2010 por Martín

El término Mongolian Horde proviene de las hordas mongolas de Genghis Khan y sus hijos que conquistaron gran parte de Asia y Europa durante los siglos 13 y 14. La estrategia que seguían en sus combates era lanzar miles y miles de soldados contra sus enemigos sobrepasándolos en número y consiguiendo victorias sencillas.



Mongolian Horde es un término que se utiliza en la actualidad en el mundo de los negocios al tratar de resolver un problema a base de asignar más y más personas a la resolución del mismo, pensando (muchas veces inocentemente) que el disponer de más personas asignadas a una tarea hará que ésta llegue satisfactoriamente a su fin. En el mundo del software este término toma relevancia especial por lo habitual que han llegado a ser este tipo de situaciones. George Stepanek lo explica muy bien en su libro "Why software projects fail":

A naive project manager who saw developers as equivalent to each other would be tempted to use the so-called "Mongolian Horde" approach, which uses a large number of cheap and inexperienced developers. Just as with the original Horde, the end result is chaos. Even allowing for their limited design and programming skills, the developers just don't have the experience to organize and deliver a system of this scale.

Some developers can even bring negative productivity to a team. They may not understand the sophistication of the team's code, and will introduce bugs that require lots of rework. They may demand so much help that their own work fails to compensate for the lost productivity of the other team members...


En uno de los últimos proyectos en los que he trabajado me encontré con algo muy similar, pero en un campo en el que nunca lo había experimentado, que es el del testing de programas. Tener testers no es algo demasiado habitual en España, salvo en grandes empresas, mientras que en Irlanda era el pan nuestro de cada día. En todos los proyectos en los que participé había un departamento separado de pruebas. No sólo eso, los testers no tenían idea de programación, ni siquiera eran informáticos. La idea es en este caso tener personas con experiencia en el negocio que aunque no esan informáticos sepan realmente como debe funcionar la aplicación, y no tenga ideas preconcebidas sobre desarrollo de software sino que se comporten como meros usuarios. No es mala idea, pero eso es otro tema.

El caso es que en uno de estos proyectos estaban unos ocho testers. Pero había un problema, nuestro software, que básicamente era una conversión entre formatos de ficheros para entornos bancarios, tenía miles y miles de posibles entradas y salidas. El equipo de testers era muy tradicional, y su lider se negaba a recibir cualquier tipo de ayuda de automatización. Esto hacía que cada vez que lanzábamos una release, que era tras tres semanas porque en desarrollo seguíamos el dictamen Agile, tenían que probar todas esas combinaciones manualmente. Algo totalmente imposible. Nunca llegaban al 20% de pruebas, así que poco a poco el producto iba ganando más y más bugs lo que nos afectaba a desarrollo.

La solución ideada por los managers fue crear una Horda de testers. Contrataron más personas e incluso una agencia externa de testing. Llegó a haber un equipo de 38 testers!!! ¿Os lo podéis imaginar en una empresa que no llega a los 100 empleados? Ni que decir tiene que la iniciativa fue un fracaso. Ellos mismos se dieron cuenta de que tener más testers no significa probar más y mejor la aplicación. De hecho el número de errores aumentó y el número de pruebas realizada disminuyó. Era simplemente demasiado complejo el controlar y formar a tanta gente en tan poco tiempo como necesitaban.

¿Cuál fue la solución? En este caso el marrón me tocó a mi, pero desde desarrollo conseguimos convencerlos de que la única opción es que nos dejasen proporcionarles herramientas para automatizar su trabajo. Lo que hicimos fue separar un grupo de swats (desarrolladores kamikaze jejeje) que creamos un sistema para que ellos pudiesen diseñar tests automatizables. Muy simple y en lenguaje natural. De modo que ellos definian los tests y por detrás nosotros lanzábamos sin que se diesen cuenta acciones de HTMLUnit que iban probrando las páginas webs. Imaginaros, un test podría ser:

- upload /tmp/Test1.xml
- Login:username=martin,password=martin
- click "Results"
- assertExists "Upload Test1.xml successful"
- Validate /results/Test1.xml

Esto es algo totalmente inventado, el lenguaje era incluso más sencillo que esto. Pero os da una idea. Además, los testers podían reutilizar los tests, para crear sus propias cadenas de tests más complejos. En un principio recibieron la herramienta con escepticismo. Ya sabeis, "Aquí vienen estos con más trabajo con lo ocupados que estamos". Pero en cuanto vieron que ahora podían repetir los tests cuando quisieran, que no tenían que andar continuamente haciendo el mismo setup manual, y que un test que les llevaba media hora hacerlo pasaba a llevarles un minuto, la historia cambio. En unas pocas semanas tenían automatizado el 30% del trabajo, mucho más de lo que habían conseguido nunca. Y lo más importante para nosotros, los desarrolladores, al incluir los tests en la build, teníamos garantía de que todo funcionaba.

No sé si alguno de vosotros habéis vivido una experiencia similar, pero os animo a compartirla. Espero que os haya interesado mi historieta.

comments

7 Respuestas a "La horda de testers"
Ibon Urrutia dijo...
12:46

Pues mi empresa debe ser una de las pocas afortunadas con un departamento de testing como el que comentas. En breve, van a disponer de la primera versión de nuestro proyecto testeable por usuarios, y la idea es que los testers graben sus sesiones con selenium, nos las envíen y las incorporemos a un trabajo que corre en nuestro hudson a las 3 de la mañana.

Además de por la automatización de los tests, no nos queda más narices que hacerlo asi, porque el departamento de testing se encuentra en Madrid, y el equipo de desarrollo en Portugalete.

En cuanto haya resultados de la experiencia procuraré comentarlos en algún sitio (abrir un blog se me está antojando interesante de nuevo).

Salu2


Martín dijo...
14:22

Me alegro Ibon. Ya contarás. Mi experiencia con darles Selenium a gente no informática no es buena. Básicamente aunque lo entiendan, no comprenden como aprovecharlo en cuanto a creación de tests sencillos, reutilización y segmentación de tests, etc.

Nosotros lo valoramos, pero preferimos montarles algo sencillo que comprendiesen fácilmente y que les hiciese natural el comprender como y por que reusar sus tests.


Ibon Urrutia dijo...
11:25

...me acabas de provocar un sudor frío por la espalda ;-)

A ver que tal sale, pero yo lo veía más como una herramienta de "grabación de sesiones": por las peculiaridades de nuestra aplicación (single-window) los tests que grabas directamente con selenium no son válidos, hay que meterles un wait después de cada instrucción. Asi que lo que nos manden va a ser "refactorizado" por nosotros.

Lo veo como una forma de evitar lo que me ha pasado otras veces con tests de usuarios: "no se a que le he dado pero me ha saltado una excepción" ;-)

Salu2


Gregorio Mena dijo...
9:20

Hola, en mi empresa también estamos intentando que las pruebas que se realizan por gente no informáticos se graben con Selenium. Como dice Ibon, por un lado tendríamos una secuencia de cómo llegar a un error, y por otro la idea es automatizar luego su trabajo. Pero pinta difícil, el primer paso (grabar los tests) se me antoja complicado... Veremos cómo sigue el intento ;)


Jordi Salvat i Alabart dijo...
0:42

Gregorio: probablemente no funcionará -- lo se porque ya ví a un test manager cometer ese error (contra la recomendación de su equipo!). El problema es que los tests grabados son muy y muy frágiles: cualquier cambio en las páginas o en su flujo os obligará a re-escribir (re-grabar) montones de tests.

Caso extremo: imagina que un día cambiais la pantalla de login. TODOS los scripts fallan -- y hay que crearlos TODOS de nuevo.

La solución es crear una librería de "pasos" que luego se encadenan para formar tests. Si cambiais una pantalla (e.g. la de login), rompeis un paso (en nuestro ejemplo el login). Reparais el paso y todos los tests vuelven a funcionar.


Martín dijo...
11:00

Jordi, cuando comentas lo de la "librería de pasos". ¿Es una librería hecha en Selenium? U os decidísteis por otra herramienta. Me interesa simplemente para saber si se puede hacer.

Como comentaba anteriormente, lo que apuntas es el fallo más grande que le vimos, por eso nos creamos nuestro propio DSL, tester-friendly, y que les permitía reutilizar tests sin afectar a la tecnología que estaba detrás de dichos tests.


Jordi Salvat i Alabart dijo...
0:36

En el único caso que lo he visto funcionar es una librería hecha en PHP atacando Selenium.

Pero es un equipo sin testers, así que no puedo recomendar esta solución para vuestro caso. Un DSL parece buena solución, si conseguís evitar que el coste de mantenerlo se dispare.