Principios esenciales para Automatización de Pruebas Funcionales

La última Testing Experience tiene un interesante artículo sobre principios para tener en cuenta al momento de automatizar tests funcionales. Los quería compartir aquí ya que me parece importante tenerlos bien presentes.

1. Primero, diseñar los tests. Evitar la creación de tests on the fly. Nuestra suite de tests debe crecer orgánicamente.

2. No automatizar todo. Ciertos tests pueden ser fácilmente ejecutados en forma manual, evitando así el alto costo de automatización.

3. Escribir tests cortos. En situaciones en las que uno o más tests fallen, cualquier miembro del equipo debe ser capaz de trackear la causa del error. Es recomendable usar BDD (Behaviour-Driven Development) 

4. Crear tests independientes. Evitar el acomplamiento y aumentar la cohesión de los tests.

5. Enfocarse sobre su readability. El código fuente de cada test debería estar self-documenting. Comentarios en el código deben ser evitados.

6. Tests deben ser rápidos. El testing funcional automatizado debe ser un indicador rápido de la calidad de la aplicación. Además, en un ambiente de continuous delivery, el tiempo de ejecución debe ser de unos pocos minutos.

7. Crear tests resistentes al cambio. Quizás esta es una de las principales desventajas de los tests funcionales automatizados. Los tests debería verificar sólo funcionalidad. Dependiendo del contexto también puede ser posible aplicar DDT (Data-Driven Testing)

8. Los tests automatizados no pueden reemplazar a los humanos. Este no debe ser el único testing que se ejecuta. Otras técnicas, con la intervención de los testers humanos, deben ser aplicadas sobre el software en pos de generar más conocimiento.

Germán

Read More

"We don't know exactly where we'll go but small steps ensure we do not fall down" [1]

Ver el todo de un proyecto es algo que puede parecer simple, pero que necesita de sus herramientas y recursos para poder hacerlo de manera controlada y efectiva.

Hasta aquí, hemos estado hablando mucho sobre agilidad y sus bondades. Sin embargo, aparece el siguiente efecto colateral: perdemos de vista "el todo" del proyecto. Es decir, ¿estamos haciendo lo que realmente debemos hacer?, ¿hacia dónde vamos? ¿dónde estamos parados actualmente luego de finalizar determinadas tareas? Si lo trasladamos a un proyecto de testing, ¿todas las funcionalidades están cubiertas por nuestras pruebas? ¿dónde nos está faltando testing? ¿cómo está el semáforo del proyecto?

Gojko Adzic, en su libro "Impact Mapping: Making a big impact with software product and projects", se encarga de tratar este tema usando los mapas mentales. Adzic, nota que una causa común de la desconexión entre el negocio y el delivery es que los equipos que trabajan en un esquema iterativo, lo hacen sobre pequeñas funcionalidades que tienden a ir por un pipeline sin tener en cuenta su valor para el negocio. Con el foco puesto principalmente en el delivery, los mapas de impacto facilitan esta vista tanto para el negocio como para el equipo técnico y se adaptan bien a los modelos iterativos. Usando mapas de impacto podemos reportar progreso, comprometernos sobre impactos a ser logrados, dar visibilidad y permitir una implementación más flexible.

Para Janet Gregory y Lisa Crispin, "look at the big picture" es uno de los factores claves de éxito según definen en su libro "Agile Testing: A Practical Guide for Testers and Agile Teams". Para ellas, todos los software makers deben mirar el todo del proyecto y usualmente desde el punto de vista del cliente. ¿Qué sucede si una nueva funcionalidad causa que otras no relacionadas rompan? Es necesario considerar el impacto sobre el sistema completo y llamar la atención del equipo sobre esto. Enfocándose puntualmente en testing, Crispin y Gregory proponen evaluar cómo las actuales stories se insertan en el esquema del negocio y preguntarnos a nosotros mismos cómo podemos hacer un mejor trabajo para poder entregar valor real. Usar el cuadrante de testing agile, guiar el desarrollo con tests, hacer testing exploratorio para aprender sobre el negocio, hacer un ambiente de pruebas tan similar al productivo como sea posible, usando datos reales y recrear situaciones en producción, tales como el testing de carga, son algunas de las herramientas que se proponen en el libro.

Personalmente, he puesto en práctica varias de estas herramientas y consejos en mis proyectos. Algunas ya las hemos charlado en el blog y otras las vamos a ir desarrollando en entradas posteriores. Sin embargo, antes de seguir avanzando, creo que es necesario ponernos a pensar si estamos viendo el todo de nuestros proyectos.

¿Ustedes lo están haciendo?

Germán

[1] Frase extraída del libro "Impact Mapping: Making a big impact with software product and projects"
[2] Imagen de http://blog.pablojimeno.com/blog/2013/03/13/london-2013-experience-part-i-impact-mapping-with-gojko-adzic/

Read More

Scrum is a Platonic Ideal

Beginning to see that Scrum is a Platonic ideal. It cannot exist in its perfect form in the real world.
— Tobias Mayer (@tobiasmayer) December 3, 2013

Read More

Kanban Maturity Chart

Hace un tiempo encontré este Kanban Maturity Chart que me pareció muy piola para mediar a nuestro equipo y usarlo en retrospectivas.

Visualize Work:  How well does the team consistently use visualization tools to make the flow of work through the system visible?

Limit WIP: Does the team set WIP limits and use them as a tool for managing flow? Do they review WIP limits, adjust them, and respect them (which is not the same as blindly obeying them)

Manage Flow: How well does the team consistently observe the flow of work using relevant measures as guides in a continuing process of reducing waste, variability, and improving the flow of work through the system?

Explicit Policies: Does the team make policies relevant to the handling of tasks clear and explicit and review those policies as needed?

Improve Collaboratively: How well does the team use models and experiments to test ideas in order to introduce improvements to the process?

Feedback Loops: How well does the team create feedback loops to give both the team and individuals actionable feedback on quality and process?


¿Ya lo probaron? ¿Lo conocían? Espero los comentarios.

Germán

Read More

LEAN

LEAN = Menos desperdicios / Más aprendizajes / Decidir al final / Entregar rápido / Potenciar al equipo / Hacer con calidad / Ver el todo

— Andres Schuschny (@schuschny) November 27, 2013

Read More

Necesitamos tener un tablero y una metodología, como sea!

A menudo sucede que me encuentro hablando con gente que piensa que hacer algo agile es implementar un tablero y con eso ya está (me ha pasado mucho en los últimos 3 o 4 meses). Verdaderamente, están haciendo algo: visualizando su trabajo en curso, sus lista de tareas y sus desvíos. Lo cual no es poco, pero...

El furor por las metodologías ágiles es tal que por momentos algunas organización necesitan aplicarlas a cualquier precio, cómo sea. Quizás sea un problema de "vacío metodológico" en dichas organizaciones, potenciado por el hecho de que algunos frameworks tiene pocas reglas, son "relativamente simple" y el tiempo de aplicación es corto. También, muchas veces existe una especie de "bajada de línea" de las gerencias sin permitir a sus equipo madurar y hacer crecer organicamente su necesidad de trabajar en un esquema colaborativo, iterativo y con todo lo que eso significa.

En conclusión, las metodologías ágiles son fáciles de aprender (son frameworks con pocas reglas) pero difíciles de aplicar correctamente. Sin embargo, pienso que también se han vuelto populares debido a que las organizaciones (no todas, pero bastantes) tienen este "vacío" que muchas veces atenta contra su buen uso.

Germán

Read More

Mapas de Impacto

Estoy leyendo el libro de Gojko Adzic, "Impact Mapping: Making a big impact with software product and projects". Me tiene bastante entretenido. Es un tema que está haciendo mucho ruido.

Personalmente, estoy intentando trabajar con mapas mentales desde hace un tiempito. Creo que es una herramienta potente que puede aplicarse a diversos dominios, tareas y/o problemas que tengamos que resolver. Sobre una aplicación puntual ya he escrito aquí.

Un mapa de impacto es un mapa mental que permite a los equipos y a las organizaciones visualizar alcance y asunciones relacionadas a algún objetivo que se intente lograr. Supongamos que, en nuestro contexto, es construir un producto software. Estos mapas son creados de manera colaborativa por todos los involucrados e interesados en lograr la meta que los convoca (obviamente, esto es una situación ideal). La gran ventaja de estos mapas: permiten tener controlada la big picture de nuestro proyecto, tener en claro a dónde queremos ir, cómo llegar y a quiénes debemos involucrar.

Durante la creación de una mapa es necesario responder a las siguientes preguntas:

• WHY? Es el centro del mapa.  Es la meta que se está tratando de lograr. Una buena meta debería ser SMART (Specific, Measurable, Action-oriented, Realistic and Timely) y presentar el problema ha ser resuelto.
• WHO? Este nivel indica quienes son los actores que pueden influenciar el resultado. Quién puede producir el efecto deseado, quién puede obstruirlo y quién será impactado. Debe ser lo más específico posible.
• HOW? Explicita el impacto que se trata de crear. Cómo debe cambiar la conducta de los actores y cómo pueden ayudar a lograrlo. Especificar estos impactos permite priorizar e identificar riesgos. 
• WHAT? El último nivel del mapa es el nivel de los entregables. Qué puede hacer el equipo o la organización para dar soporte al impacto. Puede contener varios niveles más y no necesariamente deben completarse desde el inicio. Puede ser refinado de manera iterativa.

A modo de ilustración, hice el siguiente mapa de impacto usando la herramienta MindMup. Espero que se animen a aplicarlo y a compartir la experiencia :) Voy a seguir escribiendo sobre el tema a medida que avance con el libro.

Tener +500 visitas en una entrada sobre Mapas de Impacto on MindMup

Read More

Stop Starting, Start Finishing

Hace tiempo que encontré este slide de Henrik Kniberg. Traté de implementarlo (y aún lo intento) pero algunas cuestiones son un poco más complejas. En el día a día, uno tiende mucho al multitasking y a salir corriendo atrás de las cosas que deberían haberse hecho para ayer. 

En fin, admiro a la gente que sabe decir NO y que puede tener su WIP controlado...

Read More

Algunas fotos del curso CSM

Los días Lunes 10 y Martes 11 de Junio hice el curso para la certificación Scrum Master (CSM). ¡Estuvo excelente! Muchas cosas para masticar...

Muchas gracias Alan Cyment, Diego Fontdevila y Verónica Sack. Aquí algunas fotos:

Read More

Agile is in the air

Ayer 11 de Mayo participé en el segundo encuentro del "Agile is in the air". La filosofía de estos encuentros es, básicamente, hablar de agilidad al aire libre. En el caso de ayer, la temática era "Juegos para transmitir la agilidad".

Comenzó con un Open Space para definir los temas a tratar. De aquí salieron 3 tracks con es el siguiente orden luego de una votación tipo twister: "Scrum con el cuerpo", "Gamification de Scrum" y "Juegos para retrospectivas". Sólo se trataron las dos primeros.

Les dejo el video del primer track "Scrum con el cuerpo" (faltan los subtítulos) . La idea de esta sesión era representar los roles, artefactos y encuentros de Scrum usando el cuerpo y la voz de manera que sea más fácil trasmitir y recordar las reglas del framework.

Finalmente, durante el segundo track se delineó una aplicación para gamificar equipos ágiles.

Estuvo muy bueno. Espero poder participar del próximo.

Read More

El condensador de flujo para nuestros proyectos

Sin bien la película no aclara cómo funciona exactamente, el condensador de flujo consiste en una caja con tres pequeñas lámparas incandescentes centelleantes (nuestras prácticas QA, ágiles y de desarrollo), colocadas en forma de "Y", y situada detrás entre los asientos de la máquina del tiempo. Cuando el automóvil (nuestro proyecto) se aproxima a una velocidad de 88 millas por hora (140 km/h), la luz que emiten las lámparas del condensador de flujo destellan con más rapidez, hasta emitir una luz constante (flujo constante de prácticas). Entonces el condensador se activa posibilitando el viaje en el tiempo.

Si logramos incorporar buenas prácticas a nuestro equipo y a nuestros procesos a medida que el proyecto alcanza 88 millas por hora, vamos a viajar al tiempo del "buen" software. Es el espacio/tiempo donde habitan los productos de calidad, aquellos que realmente aportan valor y desarrollados por equipos altamente motivados y skilled.

En cambio, si no logramos incorporar estas buenas prácticas a nuestro equipo y a nuestros procesos, viajaremos al tiempo del software de baja calidad, con equipos estresados y con poco valor para aportar.

Condensador de Flujo

Nota 1 (para nostálgicos): aquí dejo el momento en el que el Doc le hablaba a Marty sobre cómo viajar en el tiempo y por qué es posible aplicar esto al desarrollo de software :)

Nota 2: No creo que existan las "mejores prácticas" ya que su aplicación efectiva depende 100% del contexto en el cual serán aplicadas. Prefiero usar el concepto de "buenas prácticas" e involucrar el concepto de "contexto". Algunas prácticas pueden ser buenas para un determinado contexto y no tanto para otro.

Read More

Agile: 6 preguntas a Thomas Wallet de Pragma Consultores

Último post de la serie de entrevistas que comenzó con Leandro Caniglia, sobre desarrollo de software, y siguió con Ernesto Kiszkurno, sobre testing. Esta vez estuve charlando con Thomas Wallet, de Pragma Consultores, sobre "el mundo de la agilidad".

German Braun (GB): ¿Podría decirme, en pocas palabras, qué es "ser ágil"?

Thomas Wallet (TW): Para mi, ágil es una búsqueda, más que un estado. "Ser ágil" es estar buscando constantemente la mejora del trabajo en equipo, cuidando particularmente el compromiso con la transparencia, la auto-gestión, el desarrollo de las personas, la entrega frecuente y el feedback constante. 

GB: ¿Por qué usa y pregona el uso de metodologías ágiles?

TW: Primero, estoy personalmente muy alineado y convencido de los valores que suelen sostener las prácticas ágiles que conozco. Y segundo, porque estoy íntimamente convencido que muchas empresas funcionan mal y/o no permiten un desarrollo sano de las personas, problema al cual, la implementación de ciertas prácticas y valores ágiles, puede dar buenas respuestas. 

GB: ¿Cuáles son los mayores desafíos a la hora de implementar una metodología ágil?

TW: La resistencia al cambio de paradigma es una característica humana que suele ser la principal dificultad de las implementaciones de prácticas ágiles que he vivido. En particular, la cultura organizacional que suelen tener muchas empresas choca con los principios de transparencia y auto-gestión.

GB: ¿En qué ambientes considera que son más exitosas estas metodologías?

TW: No veo límites para la aplicación de las prácticas ágiles  Si bien son más usadas y conocidas en el desarrollo de software, se extienden cada vez más en otros dominios. Suelen ser exitosas en ambientes dinámicos con mucha presión sobre el time-to market (startups, proyectos de desarrollo en crisis, etc.). Si nos referimos al modelo de cultura organizacional de William Schneider, suele ser más sencilla la implementación de prácticas ágiles en organizaciones de Colaboración y/o Crecimiento que en organizaciones de Control y/o Capacidad.

GB: ¿Cuál es el futuro del "movimiento ágil?

TW: Creo que vamos a vivir en la próxima década una explosión de la aplicación del agilismo en otras especialidades que el desarrollo de software, al mismo tiempo que las prácticas van a ser cada vez más mainstream en el desarrollo. 

Creo que es necesario que se re-inventen nuevas metodologías ágiles, ya que las principales (Scrum, XP) rondan los 20 años de existencia. Me atrevo a predecir el futuro nacimiento de metodologías ágiles minimalistas (pocas reglas), centradas en la gestión de MMFs (Minimum Marketable Feature) y en la mejora continua. 

GB: Por último, ¿podría recomendarnos algunos blogs, podcast o libros para lectores interesados?

TW: Últimamente me interesan mucho los blogs de Tobias Mayer (http://businesscraftsmanship.com/), John Somez (http://simpleprogrammer.com/) e Yves Hanouille (http://www.hanoulle.be/).

Y dos libros que fueron mi puerta de entrada al mundo de la agilidad (aunque no sean reconocidos como libros ágiles): 

- Peopleware: Productive Projects and Teams, de Tom DeMarco y Timothy Lister

- Project Retrospectives: A Handbook for Team Reviews , de Norman Kerth

Sobre Thomas Wallet

Thomas es consultor en Pragma Consultores, con amplia experiencia en aplicación de metodologías ágiles en diferentes proyectos. Además, es autor del blog "el próximo paso".

¡Gracias Thomas!

Read More