¿Realmente necesitas una nueva herramienta para hacer ATDD?

Recientemente recibí una consulta por Twitter sobre este tema y dado que la respuesta no entraba en 140 caracteres decidí escribir este post.

Acceptance Test-Driven Development (ATDD) es una práctica de desarrollo ágil cuya popularidad está en franco ascenso. La idea es simple: guiar el desarrollo de funcionalidades a partir de sus correspondiente pruebas de aceptación. ¿Pero eso no es TDD? Si y no. Conceptualmente ATDD es como TDD en el sentido que es la prueba la guía el desarrollo, pero en general cuando hablamos de TDD estamos hablando del desarrollo de clases, una actividad que realiza el programador. Cuando hablamos de ATDD (o BDD o SBE) hablamos del desarrollo de funcionalidades desde la perspectiva del usuario lo cual requiere del trabajo conjunto del usuario y el programador. Resumiendo:

La principal diferencia entre ATDD y TDD pasa por el involucramiento del usuario en la definición de las pruebas que guiarán el desarrollo y la granularidad de las mismas.

Incluso, hay quienes afirman que el mayor beneficio de ATDD no pasa por la automatización de las pruebas sino por el involucramiento temprano del usuario en la definición de las pruebas de aceptación.

Habiendo dejado en claro los conceptos, vamos a las herramientas. Cuando hacemos TDD escribimos las pruebas en el mismo lenguaje que estamos programando nuestras clases y utilizamos para ello alguna herramienta de la familia xUnit.

Cuando hacemos ATDD escribimos pruebas de funcionalidades desde la perspectiva del usuario e idealmente lo hacemos trabajando en conjunto con él. Esto nos obliga utilizar alguna herramienta de especificación que resulte amena para el usuario quien generalmente no es alguien técnico. Dos herramientas muy difundidas en este terreno son Cucumber y Fitnesse, las cuales ofrecen un lenguaje de especificación muy amistoso y poco técnico. Luego tendremos que escribir lo que se denomina “glue code” para traducir las especificaciones escritas por el usuario a instrucciones ejecutables que se traduzcan en mensaje concretos a nuestro sistema bajo prueba. Este este sentido, puede que esa traducción ocurra a distintos niveles. O sea, una especificación del usuario podria terminar siendo una prueba a nivel de UI o bien una prueba a nivel de servicio o incluso una prueba a nivel de componente o clase. Esto no es un tema menor, ya que tiene un importante impacto en la elección de la herramienta a utilizar.

Si yo pretendo hacer ATDD generando pruebas de aceptación a nivel de componente/clase, entonces deberé elegir una herramienta que esté construida en el mismo lenguaje que mi aplicación. Pero si yo prefiriera hacer pruebas a nivel de UI, entonces tendré más libertad y podré elegir utilizar un lenguaje distinto para programar las pruebas. En este sentido conozco de varios proyectos en Android, .NET y Java, con pruebas de aceptación realizadas con Ruby. Debo admitir que cuando vi esto por primera vez, me resultó chocante, pero luego estuve involucrado en un par de proyectos en que se utilizaba esta estrategia y resultó muy cómodo.

La consulta que disparó este post tenia que ver con herramientas para hacer ATDD cuando la aplicación está construida en .NET. Mi respuesta concreta es:

  • Si el usuario va estar involucrado activamente en la escritura/validación de las pruebas y esas pruebas serán a nivel UI
    => Tienes muchas alternativas pues no estas atado a .Net. Básicamente cualquier herramienta de la familia Cucumber o Fitnesse estará bien.
  • Si el usuario va estar involucrado activamente en la escritura/validación de las pruebas y esas pruebas serán a un nivel por debajo de la UI
    => Puedes usar Specflow o Fitnesse (con su conector para net)
  • Si el usuario no va estar involucrado, entonces tienes libertad total y puedes escribir tus pruebas incluso con algo de la familia xUnit, ya que los únicos que leerán esas pruebas serán los técnicos, pero claro, ya no estarias contando con todos los beneficios de ATDD.

Dicho todo esto: ¿Realmente necesitas una nueva herramienta para hacer ATDD?

Automatización de pruebas y entrega continua en Uruguay

En 25 de noviembre voy a dictar un taller sobre estas temáticas en Uruguay con la colaboración de @pablolis. La idea de hacer un taller que una estas dos temáticas surgió a partir de reiteradas consultas que he recibido y de encontrarme hablando de una de ellas a partir de una consulta que originalmente tenía que ver con la otra.

Ante todo me parece importante dejar bien en claro la relación entre estas dos cuestiones:

  • La automatización de pruebas puede hacerse independientemente de que se trabaje en un contexto de entrega continua. Más aún, ni siquiera es necesario que se trabaje con un proceso de desarrollo en particular. No importa si se trabaja con métodos ágiles, proceso unificado o algún proceso ad-hoc, siempre puede ser valioso automatizar las pruebas.
  • Trabajar en modo entrega continua requiere indefectiblemente contar con pruebas automatizadas, pues de lo contrario, habría que invertir mucho tiempo en pruebas manuales o bien ir a producción con un producto inestable o de calidad desconocida, lo cual podria traducirse en problemas continuos más que en entrega continua.

Con esta aclaración conceptual creo que queda clara la motivación para juntar ambas cuestiones en un mismo taller.

Hablando ahora de la estructura del taller, la idea es comenzar entiendo la práctica de entrega continua, sus beneficios, fundamentos y un conjunto de patrones para su implementación. Todo esto de la mano de un conjunto de herramientas para su implementación. En este sentido compartiremos con los participantes una máquina virtual con una aplicación de ejemplo y con un set de herramientas ya instalado, listo para que puedan poner manos a la obra a medida que vamos viendo las herramientas.

En varios puntos del flujo de entrega continua nos encontraremos con pruebas automatizadas. En cada uno de esos puntos nos detendremos a analizar el tipo de prueba y las distintas alternativas de herramientas para su automatización. Por más que las pruebas y herramientas las veamos en un contexto de entrega continua, como mencioné anteriormente, las mismas también pueden resultar útiles en cualquier otro contexto.

Entre las herramientas que veremos estan: Puppet, Chef, Docker, Jenkins, Go, Travis, Cucumber, Selenium, Fitnesse y JMeter.

Los interesados pueden consultar más detalles e información para inscripción en la página de Evolución Ágil.

Agiles 2014, mi presentación sobre automatización de pruebas

Esta mañana di mi sesión sobre pruebas automatizadas. La sala estaba repleta de gente a punto tal que había gente sentada en el piso. Estimo había cerca de unas 80 personas.

Dado que yo ya sabía que no tendría tiempo suficiente para compartir todo el contenido que tenía preparado, compartí esto en con la audiencia y los invité a priorizar los temas a tratar: teoría de automatización y demostraciones de herramientas. Finalmente acordamos comenzar por los temas teóricos y dejar las demos para una sesión del open space de mañana.

Más de la mitad de los asistentes eran de perfil técnico (programadores y testers) y sólo una pequeña parte (unos 10) tenían pruebas automatizadas.

El material utilizado está disponible para descarga aquí.

sesion_agiles_2014

Clase en el posgrado de la UCA

La semana pasada dicté una clase sobre Extreme Programming en el contexto de la especialización en Ingeniería de Software de la UCA. Más concretamente la clase fue en el contexto de la materia Métodos de desarrollo de Software que dicta Andrés Diaz Pace.

Previamente Mariano Tugnarelli había dado una introducción a los métodos ágiles y Scrum. Lo cual preparó el contexto para meternos con XP.

El grupo de alumnos resultó ser bastante heterogéneo, varios de ellos trabajando activamente en el sector de software, algunos electrónicos, algunos graduados recientemente y otros hace ya bastante, en su mayoría Argentinos, pero también varios extranjeros. Muy poco con conocimientos de métodos ágiles.

Inicialmente hicimos una actividad de mitos y verdades la cual nos sirvió de disparador para ir entrando en varias conceptuales.

Algunos recursos interesante relacionados a los que vimos en la clase:

agiles_uca

#ConstruccionDeSoftware, presentación oficial DONE

El pasado 6 de Octubre realizamos la presentación oficial del libro. El acto duró aproximadamente 1 hora y salió acorde a planeado.

Comenzamos con las palabras de Alejandro Oliveros, director de la carrera de Ingeniería en Computación de UNTREF, quien destacó la importancia de que los autores, docentes universitarios y profesionales con amplia experiencia en la industria, hayan decidido volcar sus conocimientos y experiencia en la obra en cuestión.

Luego tomó la palabra Juan Gabardini, amigo y prologuista del libro, quien también hizo alguna referencia a los autores y al desafío de escribir el libro entre 6 personas.

Luego fue el turno de los autores, de antemano decidimos que no hablaríamos los 6 para que el acto no se estirara tanto. El primero fue Diego, quien habló del surgimiento de los métodos ágiles. A continuación Carlos habló sobre las motivaciones que nos llevaron a escribir este libro. Después llegó mi turno y hablé las particularidades de este libro con respecto a otros del tema. A partir de ahí el resto de la presentación estuvo dedicado a responder preguntas del auditorio y ahí sí participamos los 6 autores.

Para mi el acto fue el hito de cierre del proyecto que iniciamos los 6 autores hace más dos años. Aún hay algunas cuestiones en las que seguiremos trabajando (por ejemplo la publicación digital) pero exceden el compromiso inicial que asumimos como autores.

Más allá de las formalidades, el acto tuvo para mi cierta carga emotiva dada por la presencia de amigos y familiares.

Al mismo tiempo y más allá del producto de este trabajo que representa el libro, el proceso de escritura me resultó muy enriquecedor y me dejó muchísimas enseñanzas. Agradezco en este sentido a mis colegas co-autores por la experiencia compartida durante la escritura.

presentacion_libro

 

#ConstruccionDeSoftware, sobre los autores

Quiero dedicar algunas líneas para referirme a los autores del libro.

Los autores somos 6, tal como aparecemos en el libro: Nicolás Paez, Diego Fontdevila, Pablo Suárez, Carlos Fontela, Marcio Degiovannini y Alejandro Molinari. Todos egresados y docentes de la Facultad de Ingeniería de la Universidad de Buenos Aires. Al mismo tiempo todos nos desempeñamos en la industria del software desde hace años. Lo que hemos escrito en el libro es el resultado del estudio y la aplicación de métodos ágiles en nuestros ámbitos cotidianos a tanto a nivel académico como industrial.

Un punto interesante más allá de la cantidad de autores es que todos firmamos por el todo, o sea, el libro no es un compendio de capítulos escritos por distintos autores con opiniones distintas. Si bien hubo una división de capítulos a la hora de escribir, luego de eso, trabajamos fuertemente para acordar contenido y opiniones y asegurar la integridad conceptual de la obra.

También me parece interesante destacar la heterogeneidad de roles y experiencias entre los autores. Marcio y yo tenemos claramente un perfil muy técnico y trabajamos a diario en cuestiones de código e incluso a veces de infraestructura. Alejandro y Pablo tienen un perfil más de gestión. Carlos sin duda es el de mayor experiencia profesional pero al mismo tiempo es posiblemente el más académico de todos. Diego alterna entre cuestiones de gestión de proyecto, gestión organizacional y cuestiones técnicas. Al mismo tiempo Diego y Marcio tienen espíritu emprendedor mientras que Pablo tiene mucha experiencia en ambientes corporativos. Y lo curioso de todo esto es que esta heterogeneidad no fue planificada.

autores

#ConstruccionDeSoftware, sobre el título y la tapa

Inicialmente titulamos al libro “Desarrollo ágil” e incluso lo presentamos a la editorial con ese nombre, pero siempre supimos que deberíamos sentarnos a repensarlo.

Llegado el momento de buscar el título definitivo comenzamos compartiendo propuestas por mail, luego hicimos una sesión de brainstorming y así llegamos a 5 títulos candidatos. Luego, con esos 5 títulos, hicimos una encuesta entre un grupo de colegas y de ahí salió el título final: Construcción de software: una mirada ágil.

Respecto de la tapa, la cuestión fue menos pensada (al menos entre los autores) y creo que en un punto, y sin haberlo planeado, quedó mucho mejor de lo esperado. Nuestra idea era simple: tener en la tapa una de las imágenes del libro y el nombre de los seis autores. A partir de ahí fue todo trabajo del equipo de diseño de la editorial. La imagen de tapa pertenece al capítulo 2, donde es utilizada para explicar la idea de desarrollo iterativo e incremental.

Personalmente lo que más me gusta de la tapa es el contraste del título con la imagen y su fiel reflejo del contenido del libro. La palabra Construcción en el título sugiere algo técnico, lo cual contrasta con la imagen que muestra una persona. Este mismo contraste está planteado a lo largo de todo el libro: la construcción de software como un proceso técnico pero llevado a cabo por un conjunto de personas y gobernado por las relaciones entre estas. En este sentido hay capítulos que tratan de cuestiones plenamente técnicas como integración continua y capítulos que tratan de cuestiones completamente humanas como la comunicación entre los miembros del equipo.

Y para coronar este contraste tenemos las primeras líneas del prólogo que gentilmente escribió Juan Gabardini:

—¿Y vos qué hacés, Juan? ¿Seguís trabajando con computadoras?

—Mmm… ahora trabajo más con personas que con computadoras.

Creo que ni habiéndolo planificado habría salido mejor.

tapa_una_mirada_agil

ASSE 2014, largamos

Hoy tuvimos la primer actividad de ASSE, fue un taller de Arquitectura Emergente de dictado por Diego Fontdevila. El taller duró 4 horas y estuvo dividido en una primera parte teórica y una segunda muy práctica que sorprendió muy positivamente a los asistentes.

Del taller participamos unas 9 personas con perfiles muy variados incluyendo desde alumnos de grado hasta empresarios pasando por docentes, doctores y profesionales de la industria. Esta gran variedad resultó muy enriquecedora para las charlas y actividades del taller.

Más allá de las cuestiones compartidas en el taller, cada asistente se llevó su ejemplar de Construcción de Software: una mirada ágil.

arq_asse

Desarrollador y facilitador, no way

Como ya comenté en un artículo anterior, desde hace un tiempo estoy trabajando en un proyecto Java, una tecnología que no domino plenamente.

El miércoles pasado participé de una retrospectiva de este proyecto que fue facilitada por Alan y que me dejó pensando un buen rato. Ocurre que durante la retrospectiva Alan hizo dos sugerencias puntuales que yo mismo he hecho a otros equipos en reiteradas ocasiones pero que curiosamente esta vez no las sugerí a mi propio equipo.

Todo el viaje de vuelta a casa me lo pasé analizando esta cuestión y finalmente llegué a una conclusión que me convenció: mi falta de pleno dominio de Java me obliga a poner demasiada energía en cuestiones técnicas, lo que me hace perder de vista algunas otras cuestiones.

Luego de pensarlo por un par de días y de consultarlo con algunos amigos me animo a arriesgar:

Para que un desarrollador pueda ocupar el rol de facilitador en su equipo es necesario que tenga un buen dominio de las cuestiones técnicas con las que debe trabajar cotidianamente.

(posiblemente esta afirmación no tenga aplicación universal, pero definitivamente aplica a mi)

Se viene el libro….

Hace un par de días entró en imprenta el libro de ingeniería de software que empecé a escribir hace unos dos años junto a un grupo de colegas de la Fiuba.

La idea era escribir un libro sobre métodos ágiles, luego de un par de charlas refinamos el objetivo y decidimos escribir un libro sobre métodos ágiles que cubriera el proceso completo de desarrollo de software.

Una de las motivaciones para escribir el libro fue que no existen en la actualidad (o al menos no han tenido mayor difusión) libros escritos en castellano sobre métodos ágiles que cubran el proceso de completo de desarrollo de software. Los libros existentes sobre esta temática escritos en castellano están enfocados en algún aspecto particular. Por ejemplo los libros de Martín Alaimo tienen un foco humano/de gestión, mientras que el libro de Carlos Blé está enfocado en TDD. Existe un libro que cubre en gran medida el proceso completo de desarrollo software llamado Scrum y XP desde las trincheras, pero es una traducción de una obra originalmente en inglés.

Al mismo tiempo, la motivación va más allá del idioma. Los métodos ágiles ponen un foco importante en las personas y en ese sentido creemos que la idiosincrasia latinoamericana merece un libro a medida escrito por latinoamericanos.

El libro, más allá de lo que el título pueda sugerir, es un libro de ingeniería de software. De hecho la mayoría de los contenidos son parte de la materia que dictamos con @pablitosuarez en UNQ.

Todos los autores somos docentes y también trabajamos en la industria, por ello creemos que el libro puede resultar muy útil como libro de texto para el dictado de una materia y para profesionales de la industria con intenciones de conocer y experimentar con métodos ágiles.

En los próximos días compartiré algunos detalles y curiosidades del libro, por el momento les dejo una de las imágenes del libro que más me gusta.

15.1