TestComplete y Git

En un grupo están trabajando con TestComplete, una herramienta que permite automatizar aplicaciones de escritorio (y muchas más cosas).
Estaban manteniendo las pruebas con versionado por directorios y decidimos moverlos a git.

La solución es sencilla, ya que TestComplete tiene integración con git.

Agregar en la raíz un archivo .gitignore con contenido

Log/

Luego se pueden seguir los pasos normales para subir un proyecto existente a un repo. Por ejemplo en GitHub.

¿Y que pasa si te olvidás del paso del .gitignore?

En ese caso, la subida de los logs puede tardar mucho tiempo, incluso dar timeout. En nuestro caso, contenido completo de la carpeta del proyecto con sus logs pesaba 500Mb!

¿Cómo borrar completamente algo de Git?

Quitar de la versión

En este caso, para borrar todos los directorios Log

find . -name Log -print

Tomar de la salida todos los directorios resultantes y armar lineas como la que está a continuación, que quitan los directorios del repo local, pero lo dejan fisicamente.


git rm -r --cached <directorio>/Log

Luego podés validar que estén borrados en Git.

Ahora si, agregá el .gitignore (como está indicado arriba).



Y comitear y subir al repo. 

git status

git commit -m ‘borrar logs’
git push

Validar que en repo remoto no esten los Logs.

Quitar de toda la historia

No es común querer modificar la historia de Git. Y la forma estandard brindada por git es lenta.

Usamos una herramienta llamada BFG.

git clone --mirror https://github.com/<user>/<repo> <repo>_mirror

cp -a <repo>_mirror/ <repo>_backup/

cd <repo>_mirror
java -jar ~/Downloads/bfg-1.12.14.jar --delete-folders Log

git reflog expire --expire=now --all && git gc --prune=now --aggressive

git push

En nuestro caso, pasamos de un repositorio de más de 1Gb a uno de 380Mb.

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 (2008, 2012).

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.

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}

¿Automatizamos las pruebas de regresión?

Trabajo en una aplicación en la que cada vez que mis usuarios piden un cambio, el costo de hacer el cambio es mucho menor que el costo de probar. La aplicación no tiene automatizada la prueba y no es modular.

Esta situación la he escuchado y vivido muchas veces en mi carrera. Ante esa situación, hay varias acciones posibles:

1. Tenemos que hacer de nuevo el sistema, y esta vez lo haremos bien.
2. Redefinamos el sistema para que sea más fácil probar.
3. Automaticemos la prueba.
4. Contratemos más testers.
5. Sigamos sin cambiar durante algún tiempo.

No puedo en este post analizar todas las alternativas, pero voy a seguir una linea de razonamiento posible, asumiendo algunas creencias, básicamente que las prácticas de desarrollo ágil me pueden ayudar en este caso (Más información sobre estrategias en Working Effectively with Legacy Code). 

Entonces, la secuencia de pensamientos sería:

• Me gustaría hacerlo bien, pero no puedo tirarlo y empezar de nuevo, el negocio debe seguir operando y la aplicación se debe seguir adaptando. Entonces, trabajaremos en hacerlo bien, pero en forma incremental. 
• Para redefinir el sistema sin romperlo, y dado que trabajaremos incrementalmente (muchos pequeños cambios) necesitamos pruebas automatizadas, al menos de nivel funcional. Esto permitirá que probemos a bajo costo cada versión del sistema con un nivel aceptable de calidad. No reemplazamos las pruebas manuales, pero al menos distribuimos las pruebas entre dos ciclos: uno automatizado, rápido y frecuente, otro manual, costoso y que corremos antes de liberar versiones.
• Hacer bien la aplicación implica modularizar, tener pruebas automatizadas unitarias y calidad interna. Estas importantes ideas y prácticas no las estoy tratando en este post, pero suelen tener como precondición las pruebas funcionales automatizadas a las que me refierno en este post.

Vemos muchas equipos y empresas que siguen esta linea de pensamiento. Entonces el problema se puede reeplantear.

Quiero automatizar las pruebas de regresión, ¿cómo lo hago?

Quiero automatizar las pruebas de regresión, ¿cómo lo hago? ¿Qué herramientas uso? ¿lo hago con personas del equipo o contrato fuera? ¿cómo cambian los roles, que tenemos que aprender? ¿qué y cuánto tengo que probar para lograr confianza?

La respuesta a estas preguntas: Depende. 

Bien, pero ¿de qué depende?

El equipo ¿tiene cultura de calidad?

Algunos miembros del equipo se ocupan de la calidad, dedican tiempo a pensar como probar y manejar los riesgos. Ya se hacen pruebas, y el problema es como automatizarlas.

¿Cómo es la estructura y cuales son los conocimiento del equipo?

La prueba manual la realiza un grupo externo, o los testers del equipo (hay personas cuyo puesto o posición es Tester), o las pruebas las realizan varias personas que cubren el rol de tester, pero también otros roles (analistas, programadores, diseñadores gráficos).

Los que cumplen rol de tester, ¿tienen conocimientos sobre programación o les interesa adquirirlos?
Funciona el equipo como un Whole Team en el que todos toman responsabilidad sobre el resultado conjunto y no sobre un subconjunto ("yo pruebo, no programo" o viceversa)

¿Cómo es la tecnológicamente la aplicación?

Para disminuir la curva de aprendizaje y mejorar la aceptación de las nuevas herramientas, es conveniente que la tecnología de la prueba automática sea cercana a la utilizada para la aplicación. ¿El equipo trabaja con .Net, Java, Ruby, Python?

Nuestra respuesta

Cada equipo debe explorar qué organización, herramientas y conocimientos les servirán para su caso.

Lo que encontramos desde Kleer (en este caso Nicolás Páez, Juan Gabardini, Carlos Peix), es que solemos repetir, al inicio de las consultoría de estos temas, una mínima nivelación de conocimientos y del abanico de posibilidades en cuanto a prácticas y herramientas, para facilitar a los equipos tomar decisiones. Pensamos que sería útil extraer esto en una serie de talleres cortos (medio día cada uno):

• Taller de pruebas automatizadas: conceptos de prueba automatizada, estrategias y herramientas (lenguajes de scripting, Fitnesse, Cucumber, Selenium)

• Taller de Integración Contínua: conceptos de integración continua y automatización de builds, y herramientas (Jenkins, TeamCity y Travis).

Herramientas de Desarrollo en PHP

En los últimos tiempos estoy trabajando con varios clientes que utilizan PHP para sus desarrollos.
Hemos hablado entre varios de los involucrados, tanto de Kleer (Martín Salias, Nicolás Paez, Ignacio 'Code' Raguet) como de los clientes y nos parece que, por razones históricas, la comunidad de PHP  tiene poco incorporadas prácticas que ya están muy difundidas en las comunidades de otros lenguajes. Prácticas como análisis estático de código, criterios de calidad de código, prueba automatizada, frameworks web sencillos y potentes, y varios más. Está característica de la comunidad se reflejaba en la falta o inmadurez de las herramientas que soportan esas prácticas. Parece que esto está cambiando. 
Mi anterior post sobre PHP es viejo y  mucho a cambiado desde entonces.

Van entonces algunas herramientas y comentarios, principalmente tomado de Martín Salias, Nicolás Paez, Ignacio 'Code' Raguet y Pablo Morales. Verán que algunas cosas se repiten desde 2008, otras son nuevas.

Análisis de código 

¡Gracias Martín por la data!

• PHP_Depend es un equivalente abierto de JavaDepend y NDepend, que permite analizar dependencias, acoplamiento, complejidad ciclomática y muchas otras métricas (ver tabla de métricas)
  http://pdepend.org/
• PHP Sat: http://www.program-transformation.org/PHP/PhpSat
• PHP-AST: http://trac.assembla.com/php-ast
• PHP Code Sniffer: http://pear.php.net/package/PHP_CodeSniffer
  Tres analizadores estáticos que pueden ayudar a encontrar problemas, eligiendo las reglas que sean relevantes, se pueden poner en el build server para que se verifiquen todo el tiempo: se puede evitar que ciertos tipos de problemas vuelvan a aparecer.
  PHP Sat en particular parece tener una cantidad de reglas interesantes. 

• Varios productos de Semantic Designs:
• Clone Doctor busca código duplicado o muy similar. Puede servir para limpiar y unificar, y como guía para refactorizar.
  http://www.semanticdesigns.com/Products/Clone/
• PHP Profiler puede servir para analizar puntos críticos u optimizaciones
  http://www.semanticdesigns.com/Products/Profilers/PHPProfiler.html

• Source Code Search Engine te permite hacer queries sobre bases de código muy grandes, con más inteligencia que un grep común, entendiendo el lenguaje (soporta PHP entre muchos otros). Esto puede servir para encontrar usos de ciertos elementos, y es más un complemento que otra cosa.
  http://www.semanticdesigns.com/Products/SearchEngine/

Pruebas automatizadas 

• PHPUnit es LA elección para pruebas unitarias. SimpleTest ya no es alternativa. Por ejemplo, CakePHP pasó de SimpleTest a PHPUnit. Asociado a PHPUnit están PHP_CodeCoverage, PHPUnit_MockObject. En todas estas herramientas tiene una participación importante Sebastian Bergmann.
• Behat: es un simil Cucumber para hacer BDD.
• PHPSpec2: simil RSpec, y un comentario sobre ambos.
• Integración continua con Jenkins

Frameworks

• CakePHP: un simil Rails, en su versión 2.x está muy mejorado.
• Synfony2: históricamente con mejor 'prensa' que CakePHP, y con el empuje de estar siendo usado en Drupal.
• ZendFramework2: mucha historia, aunque quedo algo rezagado, y está intentando recuperarse.
• Silex: parecido a Sinatra.
• Laravel: un nuevo, interesante jugador
• Y más

jXmlCoverage

La cobertura ayuda a saber lo que no estamos probando. Nos ayuda poco a saber si estamos probando bien lo que estamos probando.

Hay discusión sobre la utilidad de la mediciones de cobertura. Por ejemplo ver el resumen de una discusión sobre el tema, de donde tomo la idea que lo único seguro sobre la cobertura es que nos indica que partes no hemos probado.

Por mi parte, hice un rant sobre el uso del % de cobertura como métrica, sobre todo por parte de personas que aprendieron el concepto sólo como un subproducto de TDD.

Pero si entendemos las características de la cobertura, puede ser una ayuda importante para la actividad de prueba (sea quien sea que haga esa actividad).

Hay muchos tipos de cobertura. Por ejemplo, podemos comprobar si estamos probando que se cumplan los objetivos de negocio, o los requerimientos, si hemos probado todos los riesgos identificados, todo el código o las entradas y salidas del programa.

La cobertura de código es la más común de las métricas de cobertura, quizás porque es la más fácil de medir. Incluso dentro de las cobertura de código, hay muchas posibles coberturas: de clase, de método, de linea, de instrucción, condicionales, de camino, etc.

En toda métrica de cobertura, se define el universo de los puntos posibles, y luego se mide cuantos de estos puntos están siendo cubiertos por algún caso de prueba.

Por ejemplo, en una cobertura de líneas de código, cada línea es un punto. Si esa linea es ejecutada al correr alguna prueba, se dice que ese punto está cubierto.

Se puede tomar el porcentaje de cobertura como la cantidad de puntos cubiertos sobre la cantidad total de puntos.

Pero como dijimos anteriormente, es más valioso conocer los puntos no cubiertos.

La herramienta

La herramienta que estoy por comentar, jXmlCoverage, mide cobertura basada en los XML utilizados por el Sistema bajo Prueba (en inglés, SUT).

En muchos SUT se utiliza XML, como entrada, salida o configuración. Por ejemplos, los Web Service. En estos SUT, se dispone, o se puede crear, un XSD que corresponda al contrato que daebe cumplir los XML correspondientes.

Nos interesa el grado en que nuestras pruebas ejercitan las diferentes posibilidades de valores en los XML, y sobre todo, saber que valores no estamos probando.

Para esto, debemos definir el universo que queremos medir. Lo que hacemos es, para cada elemento definido en el XSD, decidir las particiones de equivalencia que son interesantes tomar. Por ejemplo, para un entero, podrían ser los enteros positivos, el cero, los negativos y un valor fuera de rango. A esto lo llamamos subdominio. Cada subdominio es un punto sobre el que se medirá cobertura.

Pasada la etapa de definición y configuración del universo de prueba, medimos la cobertura.

Para medir la cobertura se toma el conjunto de los XML usados y se evalúan contra los subdominios, contando cuantas veces un subdominio es utilizado (cubierto) por los casos de prueba.

Como resultado, podemos obtener los subdominios que no fueron cubiertos.

Como en todas las mediciones de cobertura, se debe evitar caer en la tentación de considerar un sub-dominio cubierto como un sub-dominio bien probado.

Charlas en Exactas - UTI

Estoy participando en UTI, un equipo de administradores de IT y desarrollo web en la Facultad de Ciencias Exactas y Naturales de la UBA (Exactas, para los amigos).
El equipo de desarrollo esta conformado principalmente por estudiantes de Exactas o FADU (Facultad de Arquitectura, Diseño y Urbanismo).
Es una experiencia desafiante. Por ejemplo, en el:

• Part-time: El equipo está y estará conformado por personas part-time, con horarios cambiantes en cada cuatrimestre. Nos ha pasado tener que exforzarnos para poder estar todo el equipo junto dos veces a la semana.
• Experiencia: los alumnos se incorporan al equipo con relativamente poca experiencia, y se van del equipo cuando se reciben o antes. Hay poca experiencia en el equipo y alta rotación.
• Visibilidad: Somos un equipo chico (4 personas part-time), con muchos usuarios y sistemas en producción. ¿Cómo lograr que nuestro trabajo sea visible para la comunidad usuaria? ¿Cómo dar valor a un porcenteje alto de los usuarios durante el año?

Decidimos hacer actividades orientadas a mejorar la visibilidad e incorporar buenas prácticas: una serie de charla mensuales.
Este año hemos tenido las siguientes charlas

Control de configuración y SVN

Sergio Romano, del Grupo Esfera, comentó los principios del control de configuracón del código, y luego lo ejemplificó con Subversion (SVN).
Gracias a esta charla mejoramos y extendimos el uso de SVN. Cambiamos la estructura de los repositorios de código de nuestros proyectos.

Panel de Frameworks web MVC

Se invitaron a 4 personas a presentar sendos frameworks:

• Seam (Java) - Mariano Tugnarelli - Grupo Esfera
• Seaside (Smalltalk) - Esteban Lorenzano - Smallworks
• ASP.NET MVC (.NET) - Edgardo Rossetto - Lagash
• Ruby on Rails (Ruby) - Gustavo Andrés Brey - IBM

El panel llegó un poco tarde para la elección. Ya habíamos tomamos la decisión de usar CakePHP basados en popularidad dentro de PHP (consideramos también Symfony).
Pero fue muy útil escuchar las discuciones que surguieron. Pueden escuchar los podscast y ver el material.

Gestión de Servicios de tecnología

Sergio Villagra y Jorge Mazzini prepararon (Sergio presentó) ideas de como manejar los servicios en general y los de IT en particular.
Le habíamos pedido una charla de ITIL, pero prefirió dar una charla general sobre el manejo de servicios y luedo comentar distintos modelos. Uno de ellos es ITIL.
Aún es muy reciente y vinieron las fiestas, como para sabe como influyó en nuestro trabajo. Lo que puedo decir que despertó interés.

Y.. ¿con qué seguimos?

Las próximas charlas serán (días a confirmar y oradores TBD):

• Seguridad Web (19 de Marzo): la gran mayoría de nuestros desarrollos son web, la seguridad es un tema ineludible.
• Usabilidad (Abril 23): considerando nuestro énfasis en dar valor a los distintos usuarios de nuestros servicios (profesores e investigadores, personal no docente, alumnos, escuelas, ...), creemos que mejorar la usabilidad de nuestras aplicaciones sería muy importante.
• Single Sign On (Mayo): queremos que los usuarios puedan acceder a todos los servicios de IT brindados por la facultad autenticándose una sola vez. Un objetivo ambicioso.

Marcar tiempos en reuniones: cuenco japonés

Durante este año tuve la oportunidad de participar y facilitar en varios eventos open space (Agile Open Tour y otros).
Para el primero, Alan Cyment pidió consejo, y le recomendaron comprar una campana tibetana.
Muy buena para marcar los momentos del open space. Por ejemplo cuando se inicia, cuando se finaliza la etapa de propuestas de sesiones, al inicio de cada break y al inicio de cada tiempo de sesión.
Alan fue al barrio de Once, y consiguió una campana. Realmente funciona muy bien, lo usamos en el Agile Open Buenos Aires, y Alan se tomó el trabajo de llevarlo al Agile Open Córdoba. Por que digo que se tomó el trabajo... porque es pesada y grande!

En Tandil y La Plata nos arreglamos sin campana, pero no está bueno. Por algo fué el consejo inicial. Por eso, cuando organizábamos el evento en Bahía Blanca, se me ocurrió pedir una tapa de olla Essen. Me parece que tiene un sonido similar a la campana, pero yo no quería cargar una campana (ni una tapa) todo el camino hasta Bahía.
En eso, surgió la idea salvadora de Soledad Paredes, que nos prestó un cuenco japones, con muy buenos resultados. Es chico y transportable, y tiene muy buen sonido.
Finalmente me lo compré en www.tibet.com.ar. Me lo enviaron a domicilio. En mi caso, pedí envío por Correo Argentino y me costó $140 (35 usd) entre cuenco y envío.

Como no puede ser de otra manera, poco tiempo después lo vi en Deva's, en Agüero 1635, a metros de Santa Fe (subte D), y salía $132.
Al cuenco también lo usó Diana Larsen en el curso que tomé con ella sobre Agile Retrospectives.
En resumen, una buena compra para cualquier facilitador de reuniones con muchos asistentes, sean estas reuniones de retrospectivas, open space, u otras. Nota: tiene sentido para más de 6 personas. Para menos, no es lo mejor, aunque se puede usar la forma de tocar el cuenco frotando alrededor del borde en vez de golpearlo, lo que facilita controlar el volumen.

Pairwise testing

Cuando tenemos que probar una aplicación, el número de pruebas para hacer una prueba completa depende del número de entradas que acepta la aplicación y los valores posibles de cada entrada.
Sabemos que si intentáramos probar con todos los valores posibles, el número de pruebas se transforma en virtualmente infinita. Por eso usamos particiones de equivalencia para disminuir los valores posibles de cada entrada.

Aún así, con un número alto de entradas se produce una explosión combinatoria.
¿Cómo podemos manejarlo?
Podemos empezar probando todos los valores posibles, pero solo cambiando una variable de entrada a la vez. Esto permite que el número de casos de prueba crezca linealmente.
El siguiente paso sería probar de manera que todos los pares de valores posibles se hayan probado al menos una vez. Esta es la técnica de pairwise testing.
La técnica estricta diría que con esto ya tenemos una cobertura razonable y podremos detectar la mayoría de los errores presentes.
James Bach y Patrick Schroeder han escrito sobre limitaciones de la práctica

Hay varias herramientas, yo estuve usando jenny.

Una dificultad de jenny es que hay que hacer algunas conversiones entre los datos que usa la aplicación y los resultados de pares obtenidos.
Para facilitar un poco esto, pueden bajar el wrapper de jenny que hice.
Que hace el wrapper:

• Lee un archivo de texto con los valores posibles de cada dimensión (variable de entrada de mi aplicación)
• Cuenta cuantos valores hay en cada dimensión y invoca a jenny
• Convierte la salida de jenny nuevamente en los valores de las dimensiones

Instrucciones de uso

• Instalar Python 2.6 o posterior
• Bajar jenny.exe para MS Windows o usar el jenny que viene en el zip (es solo la compilación del código fuente)
• En un directorio poner jenny.exe, jennywrapper.py (en el zip) y dimensiones (ejemplo en el zip)
• Editar el archivo de dimensiones. El formato es:

Nombre dimensión 1
valor 1 de la dimensión 1
valor 2 de la dimensión 1
...
valor n de la dimensión 1
(linea en blanco)
Nombre dimensión 2
valor 1 de la dimensión 2
valor 2 de la dimensión 2
...
valor n de la dimensión 2
(linea en blanco)

• Ejecutar python jennywrapper.py

Indirectamente, esto está ligado a mi rant sobre la cobertura de la prueba.

Intro al testing de software en Rosario

El pasado viernes y sábado di un curso en Rosario, organizado por el Centro de Calidad e Innovación del Polo Tecnológico de Rosario, similar al que había dado hace unos meses en SADIO.
Con Fabián Longhitano estuvimos trabajando para armar el curso, balanceando horario, duración, costo y contenido, hasta lograr un producto que tuvo buena aceptación. Asistieron 26 personas.
¿Cuáles fueron los cambios? Lo más importante desde el punto de vista de contenido es que redujimos la duración a 10 hs, para que sea fuera de horario laboral. Esto implicó muchos cambios al contenido (originalmente el curso es de 16hs)

• Decidí mantener el material (tiene cambios menores con respecto al anterior), para que pueda servir de guía sobre como ampliar los temas.
• Cambié el ejercicio del Pajarraco ya que requiere al menos 90 min. Es una gran pérdida, porque este juego es muy bueno para entender el manejo de requerimientos y aceptación en ambientes ágiles, así como la dinámica de grupo y el desarrollo incrementar.
  
• Sumé el juego de los 99 globos, que también es muy bueno para ver temas de aceptación, y también conceptos de calidad desde el punto de vista de Lean, y tiene la ventaja que puede ser realizado en 30 min (aunque no es una analogía tan buena de Scrum y XP, que tuve que explicarlos, pero no practicarlos).
• Hicimos también el Origami (igual que los 99 globos, lo estuve haciendo últimamente en varios entornos). Usé principal mente para explicar el pair programing y como sirve para que los testers participen en sesiones de TDD.
  

Origami

• Quité la mayoría de los recorridos por herramientas, solamente las nombré y mostré Fitnesse. No hice una mini sesion de TDD con jUnit, ni mostré Findbugs, Hudson, SVN/Tortoise, FIT, Selenium y Marathon como hice en el curso anterior.

Aún no tengo el resultado de las encuestas, pero creo que a la gente le resultó útil.

Veremos como seguimos!

Charlas en Exactas: Panel de framework MVC para desarrollo Web

El viernes próximo tendrá lugar un panel de Frameworks Model-View-Controler (MVC) organizado por la Secretaría de Extensión, Graduados y Bienestar, que contará con la participación de los especialistas Mariano Tugnarelli (Seam), Esteban Lorenzano (Seaside), Edgardo Rossetto (ASP.NET MVC) y Gustavo Andrés Brey (Ruby on Rails). Esta es la 2da charla abierta (ver la anterior).

El panel consistirá en una primera parte en la que cada panelista presentará brevemente el framework, seguida de un espacio para preguntas a los panelista.

VIERNES 28 de AGOSTO
de 15.00 a 17.00 hs
AULA E24
PABELLÓN I de CIUDAD UNIVERSITARIA
Más info en http://www.exactas.uba.ar/uti

La descripción original del patrón Model-View-Controller fue hecha para Smalltalk en 1980. Durante un tiempo las aplicaciones web no lo utilizaron pero actualmente la existencia de frameworks potentes, que permiten completar aplicaciones muy rápidamente, hacen que la tendencia es que la mayoría de los desarrollos web utilicen alguno de los frameworks. En el panel se discutirán las ventajas y desventajas comparativas de los frameworks Seam (Java), Seaside (Smalltalk), ASP.NET MVC (.NET) y Ruby on
Rails (Ruby).

Configuración de Software y SVN

Hoy se realizó la primera charla organizada por el equipo en el que estoy trabajando en la Facultad de Ciencias Exactas y Naturales de la UBA.

Por ser la primera charla, y habiéndose retrasado por el tema de la gripe, sinceramente no esperábamos mucha asistencia. Una grata sorpresa fue que hubo unas 20-25 personas (nosotros somos 6).

En la foto se puede ver a Diego Quesada Allué presentando al disertante, Sergio Romano, del Grupo Esfera y ex-alumno de la casa.

En nuestro blog publicaremos la presentación en breve, y en una o dos semanas el video de la charla.

La próxima charla será el 28 de Agosto, un panel que discutirá sobre diferentes frameworks MVC.
¡Nos vemos!

Intro al testing en SADIO

A mediados del mes pasado di un curso sobre Introducción al Testing en SADIO.

Como siempre me pasa la primera vez que organizo cursos con alguna entidad, y a pesar de todas las experiencias previas (SADIO nos ayudó mucho en la organización de Ágiles 2008), antes del curso tenía cierta ansiedad por ver la convocatoria, que tipo de gente participa, cómo es la organización y logística del evento, etc.

Por suerte, la organización estuvo muy bien, y la convocatoria fue muy buena. Encontré a algunos comocidos, pero a muchos desconocidos, lo que es bueno! Todos muy entusiastas y comprometidos. Gente de Gral. Pico, de Córdoba, de La Plata, y por supuesto de la Cdad. de Buenos Aires. Muchos testers, algunos desarrolladores. Una pena que la gente de Córdoba no conocía al Lab de Calidad del INTI, y los cursos que dan sobre testing. Una muestra (y van ...) que los testers no tenemos una comunidad. Los pocos cursos que se dan los conocen pocas personas.

En lineas generales, el experimento salió bien. Pueden ver las transparencias y el código.

En cuanto a contenido, creo que debería haber recortado cantidad, en favor de más ejercicios. Dos días con mucha presentación se vuelve aburrido. Aún así, tuve que saltear contenido.

El códido está con NetBeans, junit, emma, y Marathon. Es el caso ultra simple de los triángulos, que usamos para hacer un brevísimo TDD (junit), mostrar cobertura (emma) y realizar pruebas automatizadas desde GUI (Marathon).

Hicimos el juego del Pajarraco, y como siempre, sirvió a su cometido: ser una referencia para todo lo que vimos después.

No me quedé conforme con la presentación de los temas de cobertura. Quedó como una presentación teórica, dada a las apuradas. No logré lo que buscaba: una herramienta y demostración sobre el valor adicional que podemos dar los testers.

Tampoco dió el tiempo para hacer prácticas sobre pruebas exploratorias, algo que me hubiera gustado.

Veremos si cambio un poco para Rosario (Agosto). Y después vienen los cursos de Automatización, en FIUBA (si logro organizarlos) y en Rosario, también con el Lab de Calidad del Polo.

Introducción al Testing de Seguridad en Aplicaciones Web

Ya está disponible en la página web del IEEE la documentación de la Conferencia 'Introducción al Testing de Seguridad en Aplicaciones Web' dictada por Andrés Riancho y Martín Tartarelli el 19 de mayo ppdo. En la misma sección también hay información sobre otras actividades realizadas en el ámbito de IEEE Argentina.

Andrés y Martín presentaron la necesidad y técnicas para realizar este tipo de pruebas. Andrés además presento la w3af, la herramienta FLOSS en que está liderando

Acceder desdehttp://www.ieee.org.ar vía Botón 'Actividades' y opción 'Documentación'.

La conferencia la organizamos junto con Marcelo Doallo (IEEE AR - computer Society).

¡Gracias, Andrés y Martín!

Popurri de Herramientas

En una de las sesiones en las que participé en Agile Open Buenos Aires 2009 nos reunimos unas 15-20 personas y comentamos las herramientas que usamos o que conocemos.

Como siempre, tuvimos que terminar con la campana (no es una metáfora, Alan Cyment, el moderador, usó una campana Tibetiana para marcar el fin e inicio de las sesiones!). Yo había pensado comentar 6 herramientas, comenté sólo 2.

El resultado, aparte de lo que nos llevamos como interacción, fue:

1- Listas de herramientas, con comentarios sobre para que sirven (ver fotos).

2- Decisión de ir subiendo esta información a agiles.org, y agregar referencias a otros sitios de herramientas, como http://www.userstories.com/products

3- Preview del proyecto FLOSS Agilar taskboard, que busca implementar las ideas de Visual Management de Xavier Quesada Allue.

Posteo las fotos de la sesión. Si alguien puede ayudar a pasarlo al formato y completar contenido para subirlo a la página, por favor que me avise.

Y se comentó sobre manejo de versiones en bases de datos, herramientas como el Migrate de RoR, y un plugin para MS SQL 2008 que mantiene versiones en SVN / SourceSafe.

Herramientas para testing en PHP

Cuando organizamos el curso de Testing con Lucas Campos, una de las dudas que teníamos era si un curso corto e introductorio serviría. Con muchos temas por tratar, debíamos restringir el número de herramientas tratadas, y necesariamente muchas serían sólo nombradas.

Nos pareció que quizás esto era un valor en sí mismo. Dar una visión de muy alto nivel de lo que considerábamos podría ser un entorno de trabajo infectado por la calidad y el testing.

Con alegría vemos que a varios de los asistentes este enfoque les sirvió para
elegir qué batallas pelear, en dónde hacer hincapié como primer experimento de mejora.

¡Pero Gabriel Maffia y Norberto Bezi, de HRSmart, dieron algunos pasos más!
En paralelo con el curso, fueron investigando, probando e implementando estas herramientas, que no fueron tratadas en el curso (Gabriel hablando):

• Continuous Integration: phpUnderControl que es básicamente un wrapper para CruiseControl que cambia el Look & Feel y te permite administrar los proyectos que tengas en el servidor de integración continua (agregar un proyecto, quitarlo, habilitar/deshabilitar tareas) con una serie de scripts.
• Unit Testing: PHPUnit implementa el framework de xUnit en PHP (no es el único, pero es el mejor y se integra con phpUnderControl). Hace también toda la parte de Coverage y Project Mess Detection (PMD).
• Análisis de Código: Usamos PHPCodeSniffer para revisar que se cumplan las coding guidelines.
  
• Documentación: Usamos Doxygen para hacer la documentación. Existe también PHPDoc pero no es tan completo como Doxygen, que genera diagramas de clase, colaboración y llamadas.
  
• Otra herramienta que todavía no probamos (y no doy fe que funcione :) ), pero que vale la pena investigar para Análisis de Dependencias: PHP_Depend
• Hay dos herramientas que si bien nosotros no las usamos esta bueno nombrar: Xinc es un servidor de integración continua escrito integramente en PHP y Phing que es un project builder como ant, pero escrito en PHP (es el que usa Xinc para correr sus tareas).
  

Por no mencionar que Norberto está trabajando en FIT para PHP...

ScrumLite: herramienta libre

ScrumLite es un producto desarrollado por Pablo Damiani y Alberto Ortega como Trabajo Profesional de la carrera de Ingeniería en Informática en la Facultad de Ingeniería de la Universidad de Buenos Aires (FI-UBA)

ScrumLite brinda soporte para administrar y controlar una cartera de proyectos basándose en Scrum como metodología ágil. Brindar información del avance y estado del mismo, valiéndose de reportes tales como el Sprint Burndown Chart y Product Burndown Chart.
El sistema contempla la asignación y definición de user stories, la administración de sprints, la definición de tareas y releases. También implementa un módulo de análisis de la calidad del código para dar soporte a procesos de mejora continua dentro de un sistema de gestión de calidad.

La aplicación fue utilizada por Southworks, empresa que certificó ISO 9001:2000, como soporte a procesos de administración de proyectos.

Scrumlite está disponible bajo licencia Ms-PL (Microsoft Public License) en codeplex


Tecnología:

• C# / .NET 3.0
• Microsoft SQL Server 2000/ 2005 / 2008
• ASP.NET 2.0 / Ajax
• WCF / Powershell
• CruiseControl

Caveat: la aplicación tiene interfase usuaria en Inglés, y la terminología no es exactamente Scrum Standard
Work Area + Commitment (ScrumLite) es similar a Ítem + Task.
Son similares porque hay una relación de alto nivel/bajo nivel, pero los Commitment son features y visibles para el cliente. Por la forma de trabajo (sprint de una semana), los commitment se acuerdan y desarrollan en poco tiempo, son chicos, no tiene sentido abrirlos en tareas.
En otras herramientas (VersionOne, por ejemplo) se permiten manejar jerarquías de items de backlog, que es un poco la idea acá, pero se mantiene el concepto de tarea.