furniture
Inflatable Water Slide

Coding Dojo

December 25th, 2009

El pasado día 22 estube en el coding dojo que organizarón la gente de agilismo.es con colaboración de autentia, os cuento un poco como fue el asunto.

La idea era realizar una pequeña clase para controlar el funcionamiento de un reloj pomodoro en el tiempo que dura un pomodoro (25 minutos), se formarón dos equipos de 5 personas cada uno (yo participe en uno aunque tampoco ayude gran cosa, eso si deje los test pasando que conste! xd). El primer equipo empezo a implementar los primeros pasos y el segundo equipo, en el que estaba yo, continuamos por donde lo dejarón los primeros. No conseguimos completar todo el ejercicio pero por lo menos nos divertimos un rato, y lo mejor de todo fue la cantidad de debates interesantes que se iban produciendo.

Para terminar jose manuel beas realizo una code kata mostrando una posible solución al problema realizada por supuesto haciendo uso de TDD. La idea de las katas esta muy bien, se trata de que alguien que ha pensado y practicado el problema durante unos días hasta dar con una solución suficientemente "pulida" demuestre la solución programandola desde cero en vivo y en directo, esto es importante porque no solo se ve "la solución final" sino que se ve también el proceso de desarrollo para llegar hasta esa solución. Vamos viendo como a través de TDD se va refinando el problema y se enfatiza el papel de TDD no como una tecnica de "pruebas" sino como una tecnica de diseño.

La verdad es que fue una tarde divertida, con un monton de gente pese a lo dificil de estas fechas (estaba "petao") y como siempre Xavi Gost en su estilo habitual showman provocador nos regalo algunas perlas xd, los operadores ternarios no le gustan mucho eso quedo claro jeje, la verdad es que fue muy divertido y con un ambiente de muy buen rollo entre todos los asistentes.

Luego por supuesto terminamos con una cañitas de rigor, la verdad es que se nos hizo un poco tarde y yo me fui sobre las 11 y media y por alli se quedarón unos cuantos valientes tomando la penultima.

Da gusto que se organizen este tipo de cosas, entre las reuniones locales del grupo de madrid de agile-spain, el agile open y estas iniciativas queda claro que se esta formando una comunidad muy activa alrededor de las metodologías ágiles y sus practicas, y es un autentico placer estar siendo participe de todo esto con tantos buenos profesionales que demuestran tanta pasión por su trabajo. Lo que nos queda es seguir apoyando y colaborando en todo esto, y a todos los que tengais posibilidad de asistir a estos eventos y reuniones: ¿a que estais esperando?.

Filed under Planeta | Comment (0)

Libros: Agile Testing (Parte 1)

December 22nd, 2009

Desde que volví del Agile Open Spain he intentado practicar el agilismo de guerrilla de Xavi Gost y, de momento, he conseguido que nos compren todos estos libros ¡Yuju! Algunos ya los he leido, pero me pareció buena idea tenerlos en la oficina por si, algún día, alguien se interesa y lee alguno. De entre los que aún tengo pendientes de leer me decidí por Agile Testing de Lisa Crispin y Janet Gregory (Si no os dicen nada estos nombres os recomiendo ojear sus twitters y blogs. Además, por si hace falta vender un poco más el libro, sabed que contiene un prefacio escrito por Mike Cohn y otro escrito por Brian Marick ¡ahí es nada!). Les pedí permiso para hacer un pequeño resumen en castellano de su libro y me lo dieron, así que... ¡Allá vamos!

Para empezar, el libro está dividido en 6 partes, así que dedicaré un post (mínimo) a cada una de las partes. Este, como ya os imagináis, está dedicado a la primera :D

Parte I: Introducción
En esta primera parte se hace un resumen de las principales diferencias entre el enfoque ágil y el enfoque tradicional basado en fases (algo que deberíamos tener todos bien claro ya). También se explora la idea del equipo multidisciplinar ágil desde el punto de vista de la calidad y las pruebas. Además, se define lo que debe ser la "mentalidad ágil para testing" y que hace que un tester tenga éxito en un equipo ágil.

Capítulo 1: De todos modos, ¿Qué es testing ágil?
Para ser ágil es necesario ser un equipo, y es necesario que todo el equipo sea consciente de la importancia que tienen las pruebas para alcanzar una calidad alta. Pero, si todo el equipo está preocupado de probar el desarrollo ¿Cómo cuadra un tester en un equipo ágil? Debe ser consciente de su situación. Cuando un equipo es ágil, los programadores prueban los casos límite (mediante TDD). Dado que el tester queda libre del trabajo de grano fino, puede centrarse en otro tipo de problemas que aporten un mayor valor al cliente (Exploratory testing, usabilidad de la aplicación, etc).
En un equipo ágil los testers no se sientan a esperar el trabajo, dan un paso adelante y buscan formas de contribuir durante todo el ciclo de desarrollo. Estas contribuciones pueden ir desde la automatización de las pruebas (en la medida de lo posible) hasta opiniones en las charlas de diseño para que el código sea más sencillo de testear.
Al ser un equipo ágil la colaboración con el cliente es la norma. El tester debe beneficiarse de esa colaboración para definir los test de aceptación de cada funcionalidad. Cuando los test demuestran que un mínimo de funcionalidad está completo el equipo puede considerar la historia terminada.
El tester de un equipo ágil debe conocer tanto el negocio como la tecnología. Debe ser el "traductor" entre negocio y tecnología.

Conclusiones del capítulo 1
  • Un tester ágil debe seguir el manifiesto ágil (Individuos e interacciones, software funcionando, colaboración con el cliente y respuesta al  cambio).
  • El testing ágil se centra en añadir valor al negocio y en entregar la calidad que el cliente solicita, diferenciándose así del testing tradicional, centrado en cumplir unos requisitos.
  • Todos los miembros del equipo es responsable de entregar software de alta calidad.
  • En caso de duda, volver a los valores y principios ágiles.


Capítulo 2: Diez principios para testers ágiles
¿Que es un tester ágil? Es un tester que acepta el cambio, sabe colaborar tanto con la gente de negocio como con la gente técnica y entiende como utilizar los test para documentar los requisitos y dirigir el diseño.
Un tester ágil no debe verse a si mismo como un policía de la calidad que protege al cliente de código inadecuado. Debe estar preparado para reunir y compartir información, para trabajar con el cliente y ayudarle a expresar sus requisitos de forma adecuada para que pueda conseguir las características que necesita y para proveer el feedback sobre el progreso del proyecto a todo el mundo.
Un tester ágil, al igual que sus compañeros de equipo, disfruta adquiriendo nuevas habilidades y no se limita a resolver únicamente problemas sobre testeo. Como cualquier otro miembro del equipo ayuda a la mejora continua tanto del proyecto como de dicho equipo.
Los 10 principios que debe seguir un tester ágil son:
  1. Provee feedback de forma continua. Dado que las pruebas dirigen el diseño, es importante que el tester se centre en expresar los requisitos del cliente en forma de tests y que trabaje de la mano del cliente para que cualquier cambio en los requisitos llegue de forma rápida y clara al equipo de desarrollo.
  2. Entrega valor al cliente. Un tester ágil permanece centrado en la visión global del proyecto. Si una característica se vuelve demasiado compleja debe analizar si conviene realizarla completa o simplemente hacer que funcione el camino normal (dejando los casos raros para otra iteración).
  3. Posibilita la comunicación cara a cara. Si hay dudas sobre una cierta funcionalidad el tester debe reunir al experto de negocio y al programador para que lo discutan. Dado que el tester entiende el negocio pero también comprende la parte técnica, puede ayudar a crear un lenguaje común entre ambos mundos.
  4. Ten coraje. Cualquier miembro de un equipo ágil debe tener coraje. Además, un tester ágil lo necesita porque, al ponerse en la situación del cliente, puede tener que decirle al equipo que algo no es correcto.
  5. Mantenlo simple. Debe hacer las pruebas más simples posibles que verifiquen que una funcionalidad satisface las exigencias del cliente respecto a la calidad del producto. Esto no quiere decir que la funcionalidad esté implementada y que funcione, eso se presupone. Se refiere a temas como el rendimiento, la seguridad, etc.
  6. Practica mejora continua. Debe buscar nuevas formas de ayudar al equipo (herramientas de automatización, unirse a listas de correo sobre testing, mejorar en el test exploratorio, leer artículos, libros y blogs para obtener nuevas ideas, etc).
  7. Responde al cambio. Mediante la automatización de las pruebas es más sencillo responder al cambio. Si todas las pruebas que realiza son manuales será imposible adaptarse a los cambios a la velocidad que exige un equipo ágil.
  8. Auto-organízate. Debe compartir con el equipo los problemas que encuentre de forma que el equipo se auto-organice para solucionar dicho problema.
  9. Céntrate en las personas. En un equipo ágil todos sus miembros son igual de importantes y los tester no están infravalorados. Un tester ágil sabe que está ayudando al equipo de una forma única.
  10. Disfruta. Trabajar en un equipo donde todos sus miembros colaboran, donde el tester está involucrado desde el principio del proyecto hasta el fin del mismo, donde los responsables de negocio trabajan junto al equipo de desarrollo y donde todo el equipo toma la responsabilidad tanto de las pruebas como de la calidad es un bonito lugar de trabajo para un tester.
¿Cómo añade valor un tester a un equipo ágil? Se está hablando de que, en un desarrollo ágil, las pruebas dirigen el desarrollo, pero se necesitan las pruebas correctas. El tester, con su capacidad para entender tanto el negocio como el lado técnico es capaz de aportar al equipo dichas pruebas.

Conclusiones del capítulo 2
  • La mentalidad de un tester ágil está centrada en el cliente, es orientada a resultados, es colaborativa y tiene muchas ganas de aprender.
  • La actitud es importante y difumina las fronteras entre los roles en un equipo ágil.
  • Los testers ágiles aplican los valores y principios ágiles (feedback, comunicación, simplicidad, entrega de valor, etc) para ayudar al equipo a identificar y entregar los requisitos del cliente.
  • Los testers ágiles añaden valor a sus equipos y organizaciones gracias a su punto de vista único.

Filed under Planeta | Comment (0)

TDD Efficacy and enemies

December 22nd, 2009
Part of this information has been got from the testdrivendevelopment group. The main enemy of TDD is.... the lazy developer. I'd rather say, the lazy programmer. It's good to read that it is just not only me who thinks that laziness is the most dangerous enemy for TDD. If you have ... Filed under Uncategorized | Comments Off

When tests gets too complex to write (and read)

December 22nd, 2009
I've realized that test code difficult to write and read is sometimes a code smell. It could mean the test code is wrong or the SUT (subject under test) itself is wrong. I've got myself thinking of how to test a method X of a class C which is calling ... Filed under Uncategorized | Comments Off

Run just a group of tests

December 22nd, 2009
Sometimes we (my team in our current project) have a single TestCase (class) holding tests for several SUTs (classes). That is not right as every class should have its own TestCase (It has to do with the fact that instantiating the tests to run them is a pain with unitttest), ... Filed under Uncategorized | Comments Off

Lista de TDD en castellano!

December 22nd, 2009
Se acaba de crear una nueva lista sobre Test Driven Development en castellano: http://groups.google.com/group/tddev-sp Muchas gracias a Jose Ramón Diaz por la iniciativa. Esperemos que los recursos en castellano sigan aumentando. Filed under Uncategorized | Comments Off

When to use mock() and proxy()

December 22nd, 2009
This is about Python Mocker features. In order to pass in a mock as a parameter to the SUT (subject under test) you might think of creating the mock using either, "mock()" method or "proxy(SomeClass)" method. They both yield mocks but they work differently. mock() should be used for stubs and ... Filed under Uncategorized | Comments Off

Conclusiones del curso de TDD

December 22nd, 2009
Ayer terminé de impartir mi primer curso de Test Driven Development de 10 horas. Anteriormente habia dado otro de unas 5 horas de duración que me dejó muy buen sabor y tenía ganas de intentarlo con otro más largo. Gracias a J.L. Roda, Pedro González y la Agencia Canaria de ... Filed under Uncategorized | Comments Off

Nice slides: TDD, design principles and the agile manifesto

December 22nd, 2009
Just wanted to share some slides regarding TDD (in English) and the agile manifesto (in Spanish). The first comes from the TDD yahoo group. The second from JM Beas and his talk at Tenerife few months ago. TDD Hands-on - Gishu Pillai Los Principios Agiles Update: Also wanted to ... Filed under Uncategorized | Comments Off

El libro sobre Test Driven Development será libre

December 22nd, 2009
De vuelta del Agile Open Spain en Madrid (evento sobre el cual escribiré en otro post), he decidido que el libro sobre Test Driven Development en el que llevo más de un año trabajando será publicado con licencia libre. Ha sido una decisión muy difícil pero el evento y las ... Filed under Uncategorized | Comments Off
« Previous Entries

-->