By Luís Fraile.
A Luís lo llevo siguiendo desde hace mucho tiempo. Junto con Rodrigo y Bruno, fueron los tres cantores que me introdujeron el gusanillo del TFS y ALM por allí por finales del 2007, principios del 2008. Y, hasta el momento, a Luís siempre lo había visto mostrando sus enormes conocimientos teóricos y prácticos en el área de gestión del ciclo de vida de proyectos.
Luego, con el tiempo y la cercanía, descubrí que es un hombre renacentista. Es decir, sabe prácticamente de todo y de prácticamente todo sabe bien. Por lo cual, y ahora que su nueva empresa es especialista en todo lo relacionado con el testing de aplicaciones, no dudé ni un segundo en irme a escuchar lo que nos iba a enseñar durante dos horas.
Me voy a permitir un breve inciso para darle un tirón de orejas a Microsoft en su vertiente de organizador. No se le puede quitar media hora a una ponencia de este estilo. Y menos para saltar de un interesantísimo tema técnico a uno de venta comercial puro. A mi, personalmente, me pareció mal. Un pequeño detalle que no quita valor a un excelente evento pero que, sin este feo detalle, hubiera sido perfecto.
Luís inició la ponencia contándonos por encima lo que significa Agile y específicamente Scrum. Para que, partiendo de la filosofía Agil, lleguemos a una automatización y optimización de las labores del testing funcional. Ojo, la charla versaba sobre Tst funcionales. Ese lado tan olvidado del test. O que a tantos les he oído decir que no son recomendables por su fragilidad. Y que a mi, personalmente, me parecen mucho más útiles que una batería de test unitarios.
Han sido muchos conceptos conocidos, y muchos a los que me ha abierto los ojos y por ende la curiosidad. Y entre ellos quisiera destacar los siguientes:
* En el equipo ideal debería existir el especialista dedicado al testing. Ya que no es una labor sencilla y necesita, además de experiencia, talento. Es curioso como hay demasiados desarrolladores que caen en “Poner al código en el centro de todo” y se piensan que con sus conocimientos basta y sobra para hacer un buen testing.
* En mis primeros pasos en el test funcional, lo he atacado desde las herramientas de Visual Studio. CodedUI. Pero debo de echarle una ojeada larga al Test Manager. Que es la herramienta de test. No el pequeño subconjunto que yo estaba utilizando. También desde aquí un tironcito de orejas a Microsoft por sacar la utilidad para modificar CodedUI en un Feature Pack, ya que no hay forma humana de probarlo a menos que tengas una suscripción Ultimate (que es una pasta impensable para una empresa pequeña)
* Aún más fuera del alcance de los mortales está el Lab Management que te permite hacer auténticas virguerías al añadirlo a la fuerza de test del Test Manager y el Visual Studio. Y digo que está fuera de los mortales porque hay que montar un pollo de dinero y de infraestructura de aúpa. Y un master para configurarlo… Pero para eso ésta TestHousing (la empresa de Luís).
* Con ello accedemos a virguerías como IntelliTrace. Una caja negra (como la de los aviones) que permite hacer un seguimiento exhaustivo de nuestra aplicación en preproducción (en producción no se aconseja por el gran impacto en el rendimiento) y que nos permite hacer una depuración del código publicado. Si, el código publicado, no el que tengo en desarrollo. Descompila el código y te permite hacer depuración como si fuera el de desarrollo!!.
* Ante la pregunta de si podíamos obtener un IntelliTrace de una máquina que no fuera de desarrollo, Luís nos comentó que si. Que tienes los servicios TestAgent y TestRunner que permite ejecutar planes de test y obtener ese chorro de información acerca del funcionamiento de la aplicación.
* Partiendo de una historia de usuario, se desarrolló un plan de test compuesto a su vez de test funcionales. Poniéndonos la gorra de tester creamos el test funcional que debe pasar la aplicación, localizamos un bug, lo documentamos y se lo pasamos al tfs en forma de workitem para que, poniéndonos la gorra de desarrollador, flipar en colores del detalle de la información de la causa del bug, corregirlo, lanzarlo en nuestra batería de test codeUI y cerrar el bug. Como tester revisar que esté corregido y cerrar el bug.
* Todo esto enlazado con integración continua. En donde me he llevado la sorpresa que tengo que ponerme con Team Build ya que ofrece un montón de ventajas en el desarrollo, aunque sea Web. Y, además, me permite utilizar MSDeploy para publicar mis web de una forma mucho más ordenada y efectiva. No como ahora que lo hago con Publish Web.
* Para rematar, estas pruebas se automatizan y se introducen automáticamente en una Build. Para que vayas construyendo una batería de pruebas funcionales y de regresión que, en mi opinión, dejan en un dudoso sitio a las pruebas unitarias. Aunque a mi me resulta muy útil las pruebas unitarias para desarrollar a nivel de método/clase (ojo, no es TDD, hago un mix. A veces antes, a veces después).
Fuera del contexto de la charla también me demostró con un simple “Ctrl + ,” la potencia oculta de los atajos de teclado, que creo que me tengo que revisar.
Por último, Luís ha dado una clase magistral de cómo mantener a un auditorio interesado durante casi dos horas en algo que haría dormir a las piedras si no se tiene el talento y la experiencia como el ponente. Pena que los compromisos comerciales de Microsoft cerrara con demasiada premura esta excelente ponencia.
Y aún quedan dos ponencias mas…
