Niveles de felicidad en el testing

En la lista de Agile Spain se está comentando un artículo muy interesante de UncleBob sobre sobre Scrum y TDD y donde Leo Antoli pregunta si se están dejando de lado las capacidades de TDD como técnica para dirigir el diseño de un sistema.

Mi opinión al respecto está en el hilo y no quería entrar demasiado en ella en este artículo. Básicamente es que veo dos líneas en TDD. Una es la centrada puramente en testing, donde gira todo en torno a JUnit y tener barras verdes, y que personalmente creo que no es aplicable a diseños complejos y serios (ojo que no digo que no se haga TDD, sino sólo que en ese contexto no me parece una técnica aplicable a a dirigir nuestros diseños) ya que tiende a la sobre-simplificación de los sistemas y a un microdiseño o microtesting.

La horda de testers

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.

Podcast sobre test de aplicaciones

En javaHispano han publicado un podcast hace unos días donde participan Alfredo Casado, Julio César Pérez y Jose Luis Bugarín y que se lo recomendaría a todo el mundo ya que explica muy bien el por qué es tan importante hacer testing, sus beneficios y todo lo que no perdemos al no hacerlo. Al igual que comentaba yo mismo en mi charla en Alicante, de la que todavía tengo pendiente el escribir varios posts, estamos en un momento donde una persona que no haga tests no se puede considerar un buen profesional. Señores, quitémonos el chip de monos picateclas porque el desarrollo de software es mucho más, y el testing es sólo una de las habilidades que un desarrollador ha de tener. Muy buen podcast.



El podcast lo podéis escuchar aquí mismo o descargaros el MP3 original desde la página de javaHispano.

Test funcionales para todos: Canoo WebTest + Grails.

Hace ya unos meses comentaba que Grails tenía sus cosas buenas y también sus cosas malas.

Pues bueno, el plugin de tests funcionales pasa a engrosar la lista de cosas que me gustan. Se trata de un plugin que integra Canoo WebTest, una fenomenal herramienta de testeo de la capa web.

Lo más importante que quiero destacar del artículo que estoy escribiendo es que no se limita a Grail. Este plugin simplemente se encarga de simular el acceso a páginas web y ejecutar un número de aserciones sobre las páginas. Los tests se escriben en Groovy y se necesita Grails para ejecutar, pero eso es todo. Es decir, podemos utilizar este sistema para testear cualquier aplicación web, ya esté hecha en Grails, en Java o en .NET. Y ya veréis que por lo sencillo que es, vale la pena.

Lo primero de todo es seguir las instrucciones del wiki, e instalar el plugin. Asumiendo que tenemos instalado Grails, tendríamos que:

• Crear el proyecto: grails create-app tests
• Instalar el plugin: grails install-plugin webtest
• Crear la carpeta de tests: grails create-webtest

Una vez hecho esto tendremos una estructura de directorios con la configuración de los tests, los reports y una carpeta "tests" donde se irán colocando los tests funcionales. Crear un tests es insultántemente sencillo, y treméndamente intuitivo. Tan sólo es cuestión de saber como trasladar el conjunto de tareas de WebTest a Groovy. Pero entre los ejemplos, y lo sencillo que es, pues no debería haber ningún problema.

Fijaros en el siguiente ejemplo de un test funcional que tenemos en Jobsket para comprobar que los perfiles de Linkedin se importan correctamente:

def testLinkedinUpload() {

invoke      '/login'
verifyText  'Entra en Jobsket'
setInputField(name:'login',value:"${user}")
setInputField(name:'password',value:"${password}")
clickButton 'Entra'

invoke '/upload/linkedin'

setInputField(name:'profile',value:'http://www.linkedin.com/in/mpermar')
setCheckbox(name:'legalAccepted')
clickButton '!Sube tu CV desde Linkedin!'

verifyText 'Tu CV'
}

¿Es necesario que explique algo del test? Nada de código Java, nada de XML, nada de scripting raro. No os exagero, hacer tests funcionales con Grails y WebTest es una gozada. El código es muy sencillo de leer, y además al ser Groovy sigues teniendo la potencia que te ofrece un lenguaje orientado a objetos y puedes agrupar funcionalidad común a los tests en otras clases. Pues por ejemplo agrupar la parte de login de ahí arriba en un método login que pondríamos en una clase padre. Es un ejemplo.

Quedaría simplemente ejecutar el test:

• grails run-webtest MiTest

Una vez se ejecutan los tests, los informes se pueden ver desde la web:



Y nada más. Simplemente resaltar lo comentado. Si estás haciendo un proyecto web, y buscas una herramienta para ejecutar tests funcionales, entonces Grails + Canoo WebTest es una opción muy recomendable. Además se integra muy bien con Hudson, pero eso lo dejo ya para otra entrada :)