lunes, 28 de diciembre de 2015

Ya no estamos en testing Kansas

Nota: El título hace referencia a "We're not in Kansas anymore", del Mago de OZ.


¿Dónde estamos?

La agilidad surgió como una revolución de una clase oprimida; la de los programadores que lucharon para liberarse de los Project Managers.

Han pasado 15 años desde el Agile Manifesto. La revolución ha cumplido su objetivo. Los programadores lograron ser reconocidos como miembros igual de importantes dentro de los equipos de desarrollo. Pero, ¿Qué pasó con los testers?

En el primer proyecto ágil en el que participó uno de los autores, el grupo estaba cambiando su forma tradicional de desarrollo de software a una dinámica ágil. Era inicialmente un grupo compuesto por tres equipos de programación y uno de testing.
Durante el cambio, algunas personas del equipo de testing se sumaron a los programadores para formar equipos de desarrollo que incorporen la calidad desde el inicio. Pero el cambio no fue completo, los testers se ocuparon en acercarse a los programadores automatizando pruebas. Pero en los últimos dos días de cada sprint, cuando se corrían las pruebas finales (automáticas y manuales) antes de liberar el producto, algunos miembros del equipo no tenían respiro (los testers), mientras otros miembros del equipo se dedicaban a jugar al Counter Strike. Eso sí, con auriculares para no molestar. En este contexto, donde la calidad esperaríamos que fuera interés de todos, las tareas de testing no las toman los programadores.
La historia que contamos muestra una implementación incompleta del enfoque Whole Team o equipo completo. Pero ¿qué pasa si logramos una buena implementación? Si todos los miembros del equipo se ocupan de la calidad, entonces ¿el tester desaparece?


El rol de tester en un equipo ágil

Si definimos lo que somos por lo que hacemos (testeo, por lo tanto soy tester) no sólo nos auto-limitamos en nuestro crecimiento personal sino que además limitamos la capacidad de nuestro equipo para encarar desafíos.  

El equipo debe tener los conocimientos y capacidad para testear, los cuales no necesariamente deben estar centralizados en una persona, sino que pueden ser parte de un rol y ese rol puede estar distribuido en varios miembros del equipo. De esta manera todo el equipo es responsable de la calidad.

El rol de testing ágil tiene algunas diferencias con el testing tradicional. En lugar de una persona exclusivamente preocupada por el detalle, el rol de testing ágil ajusta el nivel de detalle según el análisis que se esté realizando. En lugar de enfocarse en probar el producto, se ocupa en que el producto se construya con calidad.

En el testing ágil además de ser importante probar que hicimos lo que nos pidieron, resulta central considerar las razones y el contexto en el que nos lo pidieron. De esta manera, puede detectarse si estamos logrando el objetivo original, si tenemos la oportunidad de lograr un producto que exceda las expectativas y en general, sí mantenemos la mirada en la visión y los pies en la tierra. Luego, podemos distinguir el grado de importancia de los distintos temas identificados y tomar decisiones considerando esa guía: ¿Qué nos acerca a la visión? ¿Qué nos dificulta avanzar?
En resumen, consideramos que las siguientes características resultan centrales para el rol de testing ágil:

  • Comprender la visión de negocio: ¿Que proceso de negocio es el prioritario? ¿Cuáles son los objetivos y sus métricas relevantes que cierta funcionalidad intenta mejorar?
  • Conocer el proceso de desarrollo: Dentro del rol de testing ágil está trabajar continuamente para que la calidad esté incorporada al proceso de desarrollo. Si detectamos un problema en el ambiente de aceptación, tratemos de agregar un test para que la próxima vez se detecte en el ambiente de desarrollo. Optimizar el proceso muchas veces implica automatizar la prueba de regresión. Y avanzando por este camino, vemos que la calidad desde temprano nos permite más velocidad, como puede verse en Continuous delivery.
  • Saber cómo diseñar experimentos: Esto nos sirve para validar hipótesis del negocio (Lean Startup), para probar que estamos haciendo el producto correcto y bueno para nuestros clientes, como para mejorar nuestro proceso de desarrollo. También tenemos hipótesis sobre aspectos que afectan la calidad y hacemos experimentos probando el producto.
  • Conocer sobre testing en sí mismo: Es más fácil conseguir capacitación sobre programación o gestión de proyectos que sobre testing. Hay poca bibliografía y poco tiempo dedicado a la mejora del testing (katas, dojos, craftsmanship). Sin embargo hay mucho para aprender: evaluar las dimensiones de variación del sistema, identificar dimensiones válidas para probar, definir si es posible probarlas de forma independiente, etc. También resulta necesario conocer las diferentes heurísticas de prueba, los problemas comunes que dependen de la tecnología usada e identificar el conjunto que es posible probar en cada momento del desarrollo.
  • Riesgos: ¿Cuál es nuestra peor pesadilla? ¿Cuáles son las formas en que se puede romper el producto?¿Qué podemos perder, vidas, dinero, clientes? Las respuestas a estas preguntas nos orientan tanto en la definición de alcance de las pruebas como para su priorización. Conociendo los riesgos podemos elegimos cómo manejarlos. Tomar riesgos en forma controlada nos permite ir más lejos más rápido y ser más innovadores, que si quisiéramos evitar todos los riesgos. Ver mi post anterior sobre el tema.

¡Cómo que en la lista no está ...!

Algunas dudas surgen de esta enumeración: ¿qué pasa con la automatización de la prueba, la usabilidad, la seguridad?
En un equipo de desarrollo ágil es bueno que todos se ocupen en aprender sobre programación, testing, usabilidad, seguridad y probablemente otras cosas también. 
Automatizar, automatizar, automatizar: Es el mantra de todos los miembros del equipo. Es parte de lo que llamamos Conocer el proceso de desarrollo. Para ello es útil que todas las personas de equipo puedan escribir scripts al respecto, pero no necesariamente ser todos expertos en herramientas. Como testers, podemos trabajar de a pares con los expertos.
Pero no todos tienen que ser expertos en todo. Nos parece útil, por lo tanto, dejar esos temas en otros roles. Cada persona desarrolla su especialidad, profundizando y participando de comunidades de práctica. Además, aprende de sus compañeros de equipo sobre otras áreas. Entonces una persona que cubre principalmente el rol de testing, puede además conocer sobre programación lo suficiente como para automatizar situaciones normales y pedir ayuda ante problemas técnicos complejos.

¿Pero es tan distinto el testing en ambientes ágiles del testing tradicional?
Una pregunta que naturalmente surge es: ¿Cuáles de estas características no están en el rol tradicional?¿Son exclusivas del rol del testing en un ámbito ágil?

Consideramos que ninguna de las actividades es demasiado novedosa, por lo que podríamos identificar actividades equivalentes en el marco del testing tradicional. Y encontramos dos diferencias: 

No hay en el equipo una persona cuya única tarea sea probar y que concentre toda la prueba necesaria. Sí se encuentra definido un rol, que cubierto por diferentes personas, con distinto grado de involucramiento. Así es posible compartir más tiempo con otros y esto da lugar a más oportunidades de aprender, crear e innovar.

¿Y ahora qué?
Considerando la diversidad de conocimientos necesarios para cubrir de manera completa el rol del testing, es posible identificar quienes son los miembros del equipo más adecuados para cubrir esas necesidades y que ellos se interesen, no sólo por profundizar el conocimiento sobre esos temas, sino además compartirlos con los compañeros de equipo
.

Una forma es a través de lecturas. Mi lista personal de libros: Agile Testing, More Agile Testing, Explore It!, How Google Tests SoftwareThe Domain Testing Workbook, Continuous Delivery.

Además, junto con Natty y Ángel realizamos cursos on line de Agile Testing.


Origen del post y agradecimientos

Este post es uno más, dentro de mi búsqueda sobre el testing (ver lo que opinaba en 2009). Entre 2014 y 2015 presenté algunas de estas idea en JAIIO 43, Ágiles 2014 (en Open Space con Juan Diego Vasco Moncada), CAS2014 (ver la presentación más abajo) y Agile 2015.
Gracias a Natty Davidovich (), Ángel Nuñez Salazar () y Nico Paez () por las discusiones, revisiones y aportes a este post y a mi comprensión del testing.


lunes, 30 de noviembre de 2015

Difusión de las innovaciones

La difusión de las innovaciones o adopción de ideas y tecnologías sigue ciertos patrones. Distintos autores los estudiaron. El trabajo clásico sobre el tema es de Everett Rogers (Wikipedia).

En este post voy a comentar una versión alternativa que presentó Geoffrey Moore en 1991 en su libro "Crossing the Chasm".

El gráfico representa la cantidad de personas que adoptan a medida que avanza el tiempo.
En l propuesta inicial de Rogers, al principio lo adoptan los innovadores (Innovators), luego los primeros seguidores (Early adopters), la mayoría temprana (Early majority), la mayoría tardía (Late majority) y finalmente los rezagados (Laggards).
Un aporte importante de Moore es identificar que entre los primeros seguidores y la mayoría temprana se produce un quiebre importante, en el muchas innovaciones se detienen. Lo llama la brecha (the chasm).

La idea central es que las personas que adoptan ideas o tecnologías en diferentes momentos tienen necesidades distintas y que siendo conscientes del momento en que se encuentra el producto, podremos ajustar mejor la estrategia, tanto de mejora como de comunicación, para llegar a nuestros siguientes 'compradores' de la innovación:

  • Innovadores: los que siempre buscan lo nuevo, les interesa ser "los primeros en ...". Es fácil lograr que usen nuestro producto o idea, pero no les dura mucho ya que pasan a algo nuevo rápidamente. Pero mientras lo usan, lo hacen conocido a más personas y alguno de ellos se vuelve un primer seguidor. Nuestra tarea es entusiasmarlos con la potencialidad y lo novedosa que es la innovación. 
  • Primeros seguidores: a los que nuestra innovación les genera mucho beneficio. No se detienen ante los riesgos o las imperfecciones que seguramente tiene la innovación en esta instancia. Nuestra tarea es escucharlos y ajustar la innovación para que les genere más y más valor aún.
  • La brecha: es un momento de decisiones difíciles. Si seguimos ajustando la innovación a lo que nos pide cada uno de los primeros seguidores, nunca llegaremos al gran público. En tecnología, seguiremos agregando más y más funcionalidad o detalles, cada uno de ellos relevantes solo para un pequeño número de interesados. Necesitamos un cambio de foco, que nos alejará de nuestro soporte actual (los primeros seguidores) y quizás pase un tiempo hasta que ganemos a la mayoría temprana. Nuestra tarea es trabajar en hacer la innovación sencilla de comunicar, de adoptar y de usar, confiable, con soporte ante inconvenientes.
  • Mayoría temprana: a los que nuestra innovación les genera valor, pero no están dispuestos a tomar riesgos elevados. Los convencen las historias de éxitos de otros que ya pasaron por la adopción. Están dispuestos a pagar por la innovación. En esta etapa el crecimiento de la adopción es explosivo. Moore escribió sobre esto en su libro "Inside the tormado". Nuestra tarea es escalar para sostener la demanda. El limitante para el crecimiento en adopción es nuestra capacidad para escalar.
  • Mayoría tardía: los que incorporan la innovación cuando ya no es innovadora. Son los adversos al riesgo. Cuando más del 50% adoptó una idea, empieza a ser más riesgoso no adoptarla. Es muy probable que haya aparecido competencia. Nuestra tarea es mostrar que somos la opción más segura y trabajar en optimizar los procesos operativos (por ejemplo, tener costos bajos).
  • Rezagados: lo reticentes. Es un mercado relativamente chico, difícil de alcanzar y con poco margen.

viernes, 30 de octubre de 2015

Intro a TDD en formato autoaprendizaje

Les comparto un material que he usado un par de veces para difudir TDD en forma de autoaprendizaje o con relativamente poco soporte por parte del facilitador.

Motivación

Hace un tiempo facilitamos con Pablo Tortorella un Hackathon en el Instituto ORT de Almagro. Durante el diseño del evento (con gente de ORT como Damian Rosenfeld, Alejandro Jait y otros), surgió el interés que los asistentes, en su mayoría alumnos del Instituto, pudieran aprender algo nuevo, si no les entusiasmaba ninguno de los proyectos, o como una forma de alternar el foco.
Para eso requeríamos un material de aprendizaje autónomo.

Material

El material que contruimos es un poster en tamaño A3 que incluye una descripción de un ejercicio a realizar, un gráfico de el ciclo de TDD, y algunas consideraciones del por qué del TDD.
También referenciamos a videos cortos (de 5 min) en los que Martín Salias explica como hacer un 'hola mundo' de TDD en Java, .Net, y Python.




Feedback!

Si lo usas y encotras algo para mejorar, por favor me comentas.


lunes, 31 de agosto de 2015

Agilidad fuera de software a través de espacios de co-creación

¿Qué tienen en común proyectos tan distintos como movilidad sustentable, tratamientos médicos prolongados y enseñanza a personas con autismo?

Entre mayo y junio pasado participamos en un proceso de aceleración de proyectos del Gobierno de la Ciudad de Buenos Aires en el que se conjugaron varias características que vemos emerger en los procesos de innovación.
A continuación les contaré lo que encontramos de común en estos proyectos y en su proceso de aceleración:
  • ¿Son los participantes?
    No parece ser el caso. En los proyectos participan diferentes organismos del estado, empresas, universidades, ONG e individuos.
  • ¿Los une la forma de financiamiento?
    Tampoco. Cada proyecto se financia de manera distinta: en algunos casos son iniciativas personales, en otros, investigaciones universitarias, presupuesto de áreas del gobierno, donaciones y trabajo de voluntarios, o inversión empresarial. 
  • ¿Coinciden en el estado de avance?
    No. Había proyectos en todos los estados, desde iniciativas individuales sin equipo, otros con planes presentados a inversionistas, otros con prototipos y aún productos y servicios ya producidos. 

Entonces, ¿qué encontramos en común?

El espacio de innovación

Hay elementos presentes en la mayoría de las innovaciones: la suma de ideas crea saltos de innovación, las ideas toman tiempo para convertirse en innovaciones, la innovación pasa por distintos estadíos (divergencia, selección, convergencia, enriquecimiento).
¿Qué puede hacer alguien que quiere incentivar la innovación en otros? 
Crear espacios, ajustados a cada estadío, que faciliten la diversidad y el intercambio de ideas, dando tiempo para su maduración, pero también foco y límites para que avancen en cuanto a su realización.

Esta creación de espacio es transparente para los asistentes. Sólo se ve que hay gente interesante presente, que hay sillas y mesas suficientes, comida y bebida, papeles, marcadores y otros elementos que permiten a los asistentes enfocarse en la interacción entre ellos. Además, en cada momento está claro qué queremos lograr y siempre tenemos a quién pedir u ofrecer ayuda.

Una descripción muy buena de esta actividad es el concepto de Host Leadership. En este enfoque del liderazgo se plantea roles y posiciones. Los roles reflejan distintas acciones y estilos, como Iniciador, el que Invita, Creador de espacios, Protector del espacio, Conector y Co-participante. También el líder puede cumplir su rol desde diferentes posiciones: en el Escenario, Entre la gente, en un Balcón, o en la Cocina. Combinaciones entre rol y posición pueden ser necesarios en diferentes momentos y por diferentes personas.


Lo visual

La información visual es la forma predominante de intercambiar información en la mayoría de las personas. El uso de facilitación gráfica para expresar lo conceptos, los prototipos en papel, el uso de notas autoadhesivas para proponer y luego reordenar las ideas, todo esto promueve la comunicación y la comprensión rápida.
Además, hay un resultado indirecto de estas actividades. Se crea un espacio de emociones positivas y de seguridad, que promueve la creatividad y la colaboración.

Hacia el final de un curso con alto componente técnico, realizado en un laboratorio de una universidad, las paredes estaban cubiertas con grande papeles de gráficos y dibujos, y notas autoadhesivas de colores formando listas y tablas llenas. En un momento entra una persona de la universidad ajena al curso, y mirando alrededor comenta "¡Qué increíble! ¡cómo cambia el laboratorio con tantos colores!".

El aprendizaje rápido

Los proyectos de años de duración, definidos completamente al inicio, son cosa del pasado. Ni los clientes esperan, ni los inversores ponen dinero sólo por una presentación, ni los visionarios y emprendedores confían sólo en intuiciones.

Ahora escuchamos a los clientes y buscamos satisfacer sus necesidades, creemos que la mejor forma de saber que le estemos dando valor es llevando nuestro producto o servicio rápidamente a sus manos, mirar cómo lo usa, escuchar lo que dice y aprender para modificar nuestro producto.
En esta forma de innovar desconfiamos de nuestras hipótesis e intuiciones, buscamos la manera más rápida de validarlas y aprender en el proceso. Design Thinking y Lean Startup son algunas de las formas interesantes de descubrir lo que se necesita y como tiene que ser el producto que lo resuelva.

Para que esto sea posible, necesitamos poder construir y adaptar nuestro producto en pequeños incrementos, a bajo costo. En cada tipo de producto esto se logra de manera distinta, así como fue el Desarrollo Ágil para el software, hay otras formas en cada área de conocimiento para lograr esto. Lean Thinking es la descripción genérica de esta forma de trabajo.


La colaboración

Si queremos innovación a través de sinergias y suma de ideas, es imprescindible la colaboración. Parte de esto está fomentado por los espacios y lo visual, que comentamos antes. Pero eso solo no es suficiente. Los equipos recién formados no siempre colaboran, hay choques de personalidad y malos entendidos por desconocimiento mutuo.

Es importante en esta situación el rol del facilitador, que guía la dinámica del grupo, para que sea un grupo efectivo. Por ejemplo, validando a supuestos e inferencias, compartiendo la información relevante, usando ejemplos específicos, acordando el significado de términos importantes, explicando los razonamientos e intenciones, focalizando en intereses en vez de posiciones, combinando entusiasmo en exponer ideas con indagación de otras ideas, diseño conjunto de pasos y paneras para resolver desacuerdos, hablar aún sobre los temas tabúes y usar reglas de toma de decisiones que generen el nivel de compromiso necesario (Skilled Facilitator).

¿Cuándo ocurre?

Estamos viendo estos espacios de co-creación dentro de empresas, organizadas por empresas con su ecosistema de proveedores, entre empresas amigas, alrededor de comunidades de meetup, organizadas por entidades del estados y un largo etc.

Creemos que estos espacios de co-creación pueden ocurrir espontáneamente, sin embargo podemos ayudar a que ocurran, como hemos visto hacer y hemos hecho.

¡Inténtalo!


Gracias a Pablo Mazzeo conozco sobre Host Leadership, y gracias a Alan Cyment, Skilled Facilitator.
Las experiencias que comento las viví gracias a Kleer, Rutan Medellín, el Ministerio de Modernización del GCBA y el Cluster Ágil.

miércoles, 15 de abril de 2015

Arquitectura de la prueba automatizada



La automatización de la prueba de software es un tipo particular de sistema de software, a veces llamado framework de prueba o stack de prueba.
Como cualquier sistema de software, tiene una arquitectura que puede facilitar o no la extensión, reuso y modificación. 
Arquitectura del Sistema de pruebas automáticas

Una arquitectura compartida

Algunas familias de herramientas de prueba (como Mercury, Rational, Silk y TestComplete) están pensadas para resolver toda la problemática de la prueba y tienen la arquitectura definida por el fabricante.
En otros casos (como Selenium, FitNesse, Cucumber y RobotFramework) las herramientas resuelven sólo algunos de los aspectos de la prueba. Suelen usarse combinadas con otras herramientas.
Una discusión que dejo pendiente es la correlación entre los atributos de las arquitecturas (extensión, reuso y modificación) y el origen de las herramientas: propietarias o FLOSS.

Planteo entonces por mi cuenta una arquitectura que describe muchos de los stack de prueba que conozco. 
Esta arquitectura está en movimiento aún. Hace un año aproximadamente incorporé el componente Comparator por conversaciones con Nicolás Páez (él plantea un modelo ligeramente distinto parte 1/parte 2). En enero de este año, cuando estaba explicando la arquitectura, me surgió la necesidad de agregar el Editor.
Y aún tengo dudas sobre la utilidad de separar algunos componentes, como por ejemplo tener componentes separados para reflejar el mecanismo de extender el DSL, tanto del lado del Test Case como del Interpreter.

Para qué buscar una arquitectura compartida

Identificar una arquitectura común de las herramientas de prueba permitiría simplificar las interfaces y que cada producto tenga foco en su especialidad, sabiendo que otros productos se ocuparán de las restantes áreas. Esperaba que el programa de la Agile Alliance "Agile Alliance Functional Testing Tools" lograra este consenso. No encuentro que se haya publicado ese análisis, aunque hay otros temas interesantes (20082012).

Es también útil tener un lenguaje común para poder discutir stacks alternativos cuando se está diseñando una solución de prueba.  

Los componentes

Por cada componente, describo brevemente el alcance del mismo y algunos ejemplos de su instanciación en herramientas existentes.
  • Editor: cómo creo y edito mis casos de prueba. En ocasiones una herramienta ad hoc, en otros casos una herramienta genérica.
    Selenium: Selenium IDE, permite grabar acciones desde la aplicación o editar los TC.
    WebDriver: editor/IDE del lenguaje de programación usado. 

    RobotFramework: RIDE, permite editar TC en forma 'inteligente', o editores de HTML. 
    FIT: Word, Excel y editores de HTML. 
    FitNesse: wiki. 
    Cucumber: cualquier editor de texto.
  • Test Case (TC): Repositorio de mis casos de prueba, con o sin estructura y con un lenguaje con el que escribo mis casos de prueba. Puede incorporar la posibilidad de definir términos nuevos que abstraigan complejidad.
    Selenium IDE: Los casos de prueba se escriben con Selenese, básicamente un HTML con una tabla de tres columnas. La estructura de casos está dada por las suite, que es una tabla HTML con los casos.
    WebDriver: No tiene forma nativa de representar los casos de prueba o la estructura. Debe usarse un Runner de otra herramienta y sintaxis de lenguaje de programación usado. Extensión usando el lenguaje de programación.
    RobotFramework: HTML (tablas), TSV, reST. Permiten extender el DSL de prueba con user keywords.

    FitNesse: wiki markup languaje (tablas). Permiten extender el DSL de prueba con Scenario.
    Cucumber: Gherkin y permiten extender el DSL de prueba con Scenario Outlines.
  • Interpreter: interprete del lenguaje de TC, incluyendo mecanismos para definir o extender un DSL.
    Selenium: plugin de Firefox, y se extiende con plugins adicionales.
    WebDriver: la parte correspondiente a WebDriver es interpretada o compilada por el lenguaje en el que se escribieron los TC (Java, Ruby, Python, etc), y resuelto con la API provista por la biblioteca de Selenium.
    RobotFramework: interprete del lenguaje propio (test data syntax), se extiende con  
    library keywords.
    FitNesse: interprete de HTML (modo compatibilidad con FIT) a través de una conversión interna entre wiki text y HTML, o directamente wiki text en el caso de SLIM. Extensión usando Fixture.
    Cucumber: interprete de Gherkin más los steps creados.
  • Adapter: cero, uno o más capas de adaptación entre los TC interpretados y el sistema bajo prueba (System Under Test o SUT). La forma de conexión depende del tipo de prueba que se quiere hacer, por ejemplo conexión con: interfaz usuario, API REST, u objetos de la aplicación.
    SUT Web: un ejemplo sería WebDriver usado para automatizar la aplicación a través de la interfaz web, más PhantonJs para simular un browser.
    SUT Desktop: un ejempo es Abbot para pruebas de Java Swing o White para pruebas GUI sobre Windows usando UIAutomation.
  • Comparator: el mecanismo de comparación entre resultados esperados y los resultados reales. El comparador puede tener conocimiento semántico y sintáctico sobre el resultado (Output) del SUT, para poder hacer comparaciones más significativas y concisas. En este sentido puede estar ligado a los adapters. En otras casos está implementado en el Interpreter. Y también puede ser extendido.
    Cucumber: la base de los comparadores corresponde a las expectations de RSpec, pero se enriquecer, por ejemplo con los Capybara Matchers.
    Fitnesse: una de las diferencias entre el Interprete FIT y SLIM es los comparadores adicionales (rangos, aproximados, mayor o menor). Adicionalmente, en SLIM se pueden enriquecer con Custom Comparators.
  • Runner: permite correr los TC. Pueden permitir ejecutar TC secuencialmente o en paralelo; todos los TC, o algún subconjunto (los que tienen cierta marca o tag, los que han fallado, etc), o uno solo TC; indicar dependencias entre TC.
    Los Runner también tiene mecanismos para indicar cuando un TC ejecutado ha sido exitoso o no y  mecanismos de preparación y limpieza de las pruebas. Invocan a la generación de reportes.
    Cucumber: se invoca por linea de comando y puede usarse el runner de JUnit (con cucumber-JVM)
    FitNesse: se puede ejecutar las pruebas desde la wiki, por linea de comandos, por servicios REST y puede usarse el runner de JUnit.
  • Reporter: crea los reportes de seguimiento de los resultados de la prueba. Distintos usuarios del sistema de pruebas requieren distintos reportes: resumen al momento, evolución temporal, detalle de casos ejecutados, etc. Es este área el formato XML de JUnit es el standard de facto. Aunque varias herramientas tienen alternativas: sólo texto o HMTL. Además, se incorporan a otras herramientas para brindar visibilidad, como Jenkins o SonarQube.

Conclusiones

Los equipos de desarrollo de software pueden diseñar su sistema de pruebas automáticas en forma iterativa e incremental, de igual manera a como se desarrolla el producto. Se empieza por la forma más sencilla y se mejora cuando es necesario.

Espero que este modelo te ayude a evaluar alternativas y decidir que cambiar en cada ciclo de mejora.

lunes, 12 de enero de 2015

Fitnesse con Python (waferslim)

En estos días tuve la necesidad, por primera vez, de usar Fitnesse para probar un sistema escrito con Python.
Gracias a SLiM es fácil, comparado con la implementación con FIT, relacionar Fitnesse con varios lenguajes.
Me llevó, de todas formas, más de un par de horas hacerlo funcionar. Espero que a otros les sirva.
Nota: Mis pruebas fueron con Ubuntu 14.04 y 11.04

Los pasos para ponerlo en marcha son:
  1. Instalar WaferSLiM, el servidor SLiM para Python.
  2. Instalar Fitnesse
  3. Configurar las pruebas para usar WaferSLiM y la versión correcta de protocolo

WaferSLiM

Obtener waferslim desde https://pypi.python.org/pypi/waferslim
wget https://pypi.python.org/packages/source/w/waferslim/waferslim-1.0.2-py2.6.zip#md5=acacf783444802677358b8b301ab23f9  --no-check-certificate
unzip waferslim-1.0.2-py2.6.zip

Instalar waferslim por https://bugs.launchpad.net/ubuntu/+source/distribute/+bug/958550

sudo easy_install ez_setup
cd waferslim-1.0.2
sudo python setup.py install

Para probar que todo anda bien (reemplazar el syspath donde lo hayas instalado)

python -m waferslim.server --syspath /home/kleer/waferslim-1.0.2 8002

Fitnesse

Obtener Fitnesse de http://www.fitnesse.org/FitNesseDownload el release 20140901
fitnesse-standalone.jar (*)

Para probar, ejecutar
java -jar fitnesse.jar -p 8000

Abrir en un browser localhost:8000

Configuración

Crear una página de Test y poner este texto, reemplazando el path por el correcto en tu caso (*)

!define TEST_SYSTEM {slim}
!define SLIM_VERSION {0.1}
!path /home/kleer/waferslim-1.0.2
!define COMMAND_PATTERN {python -m waferslim.server -v --syspath %p }

Luego poner el test, tomado del docstring de algunos de los ejemplos que se encuentran en la distribución de WaferSlim. Por ejemplo

|import|
|waferslim.examples.decision_table|

|should I buy milk|
|cash in wallet|credit card|pints of milk remaining|go to store?|
|      0       |    no     |      0                |    no      |
|      10      |    no     |      0                |    yes     |
|      0       |    yes    |      0                |    yes     |
|      10      |    yes    |      0                |    yes     |
|      0       |    no     |      1                |    no      |
|      10      |    no     |      1                |    no      |
|      0       |    yes    |      1                |    no      |
|      10      |    yes    |      1                |    nope    |

|should I buy milk alternative implementation|
|cash in wallet|credit card|pints of milk remaining|go to store?|
|      0       |    no     |      0                |    no      |
|      10      |    no     |      0                |    yes     |
|      0       |    yes    |      0                |    yes     |
|      10      |    yes    |      0                |    yes     |
|      0       |    no     |      1                |    no      |
|      10      |    no     |      1                |    no      |
|      0       |    yes    |      1                |    no      |
|      10      |    yes    |      1                |    nope    |


Apretar el botón de test y ¡listo!

(*) Versión del protocolo

La versión de WaferSlim que se encuentra en pypi fue probada con el fitnesse.jar release 20100103.
Si se usa esa versión de Fitnesse, no es necesario configurar SLIM_VERSION {0.1}

martes, 15 de abril de 2014

Reporte de defectos (bugs) en Scrum

Una pregunta muy frecuente en los equipos que están implementando Scrum es si tienen que seguir usando una herramienta de seguimiento de defectos, y si lo uso que deberían registrar en la misma.

Veamos primero la respuesta revolucionaria y después una respuesta evolutiva. 
Y luego el análisis en cuanto al momento en que se detecta.

Nota: en todos los casos que comentamos, la importancia o prioridad de los bugs se debe acordar en el Scrum Team (Dev Team + Product Owner + Scrum Master), teniendo la última palabra el PO basado en el impacto en el negocio.

Revolución: Hay una sola lista de pendientes

El backlog contiene todo lo que hay que construir. No hacemos diferencia entre bug y funcionalidad nueva.
Un bug que provoca que las pruebas automáticas estén en rojo (falla alguna de las pruebas) debe corregirse en el momento o esa funcionalidad debe quitarse (o desactivarse).
Si encontramos un bug durante la prueba exploratoria que es crítico, agregamos una prueba automática que lo evidencie. 
Todo otro bug se considera un cambio a una funcionalidad existente y se prioriza junto con otras funcionalidades.

Evolución (orgánico): Lista de bugs

El Product Owner dispone de varias fuentes: pedidos de los clientes, ideas propias de nueva funcionalidad, y un lista de los bugs que persisten en el producto. Cuando se planifica el sprint, se consideran los bugs más complejos como nuevos requerimientos, y los chicos se agrupan en paquetes de corrección. En ocasiones se define un tiempo fijo que se dedicará a corrección de todos los bugs que se puedan.

Caso bug detectado en una historia que se está desarrollando

  • Primera opción, corregirlo dentro del sprint como parte del desarrollo de la historia
  • ¿Y qué pasa si no llegamos con todo lo comprometido? 
    • Recortar la funcionalidad para que ese bug no sea relevante y agregar una historia con esa funcionalidad recortada. 
    • Si es muy grave, quitar la funcionalidad correspondiente y la historia queda sin hacer. Quizás pueda resolverse e el próximo sprint.
    • El bug es poco importante como para hacer alguna de las anteriores: si no es importante ahora, ¿cuándo lo será? Podemos registrarlo en una herramienta o tiralo a la basura, si aparece alguien a quien le importe, lo pedirá. Esta última es la forma más realista en el largo plazo. Las listas interminables acumuladas de bugs son un consumo de tiempo y esfuerzo de todo el equipo.

Caso bug detectado luego de liberada una historia

Hay varias alternativas:
  • Se maneja como una historia de usuario (si es grande)
  • Se agrega a las lista de ideas a revisar en el refinamiento de backlog, tanto para estimar como para evaluar la prioridad. Luego del análisis, se carga en el backlog / lista de bug si se quiere corregir en los próximos sprints, o se descarta.
  • Se corrige a medida que aparecen. El equipo debe manejar el impacto en cuanto a cambio de alcance. Por ejemplo: tener un tiempo fijo dedicado en el sprint para corrección de bugs. O poner un límite de bugs abiertos (por ejemplo 10) y se debe detener el desarrollo de nueva funcionalidad hasta tanto se corrijan los bugs que hay en exceso. 

¡Espero este breve recorrido te ayude!