miércoles, 26 de agosto de 2009

El % cobertura no significa nada

Los que venimos del testing, que raro nos suena escuchar a programadores hablar sobre la calidad del software. ¿No es ese nuestro terreno?

La llegada del desarrollo Ágil a creado muchas mejoras en la forma de trabajo. El énfasis en la calidad ha logrado que muchos programadores incorporen la idea de testing como algo necesario en el proceso de desarrollo.

Los test unitarios, hace no mucho tiempo un lujo poco frecuente, se han ido incorporando como una buena práctica en muchos equipos. Esto, junto con otras prácticas como integración continua, pair programming e involucramiento del cliente durante toda la duración del proyecto han requerido un cambio de las actividades realizadas por los miembros del equipo (como ejemplo, ver mi visión sobre los cambios de los testers en Tester's Dilemma, para el caso de los analistas, puede verse la presentación de Cooper).

Pero los cambios también trajeron algunos nuevos problemas. En los últimos tiempos he escuchado discusiones entre personas a las que respeto mucho sobre si es posible o no llegar al 100% de cobertura. En una reciente discusión en foro-agiles, se ha propuesto un umbral de % de cobertura como una requerimiento contractual para equipos externos (outsourcing).

Por un lado... ¡música para mis oídos! Prefiero mil veces discusciones sobre cuánto debemos probar y cómo (automatizado vs exploratorio, unitario vs integración vs sistema, …), quién (testers, programadores) antes que discutir sobre si tenemos o no que probar.

Por otro lado...

¡El porcentaje de cobertura no significa nada!

Bien, ya tiré la bomba... ahora a tratar de justificarlo.

Desmenucemos un poco el problema. Cuando un programador habla de cobertura, en general se refiere a cobertura de lineas de código por pruebas unitarias automáticas. Empiezo entonces por mostrar que la cobertura, en ese sentido, puede no significar mucho. Luego vamos por los otros significados que puede tener la cobertura.


Cobertura de lineas de código por pruebas unitarias automáticas

¿Qué queremos medir? Si estamos trabajando en un equipo de desarrollo ágil, quizás estemos trabajando con TDD, en cuyo caso estrictamente no deberíamos escribir lineas de código sin que estas correspondan a un test que falle.

En este sentido, si tenemos un equipo que trabaja a conciencia, podríamos asumir que un porcentaje alto de cobertura es la consecuencia esperable de tener buenos casos de prueba y que estamos siguiendo la práctica de TDD.

Pero TDD está muy asociado a refactoriong, y el refactoring aplica tanto al código del producto como al código de la prueba. Podemos hacer refactoring tranquilos, siempre que los test sigan corriendo verdes, no?

Hagamos un experimento:

  1. Tomo mi proyecto estrella, con buena cobertura de pruebas.

  2. Refactor: quito todo el código innecesario en las pruebas (me refiero a todas las llamadas a assertXXX)

  3. Corro las pruebas. Pasan (verde) y ¡¡con la misma cobertura que antes!!


¿Qué falló?

Luego de eliminar los assert mis pruebas son apenas mejores que un compilador con checkeo de tipos (tema para alguna tesis :) ).

Entre la prueba automática y el producto se mantiene una coherencia y sincronización, justamente esto es lo que nos permite decir que, a diferencia de los diseños en documentos, las pruebas automatizadas deben estar siempre actualizadas. Pero la relación entre el código del producto y las pruebas no es simétrica. Si tengo pruebas de mala calidad, el código del producto no las detectan.

¿Cómo podría medir la calidad de mis pruebas? Este es un tema muy interesante, y una razón por la que deberías tener testers en el equipo :D. Como ejemplo, algo que se puede hacer es mutation testing: modificar el producto (aka inyectar errores) para ver si las pruebas detectan los errores inyectados.

Otras coberturas por pruebas unitarias automáticas

En herramientas de medición de cobertura se pueden medir distintos tipos de cobertura. Por ejemplo en Java (con EMMA) se puede medir cobertura por paquete, por clase o por línea. También se podría medir cobertura por función o por expresión. Todas estas, con la idea que cobertura significa que en algún momento se haya ejecutado esa parte del código.

Sin intentar hacer un tratado sobre coberturas, nombro otras:

  • Flujo de datos: el comportamiento puede depender de los datos. En el ejemplo, si tengo una sola prueba assertEquals(2,dividir(4,2)); tengo 100% cobertura pero no estoy probando el caso relevante dividir(x,0)

Código a probar: int dividir(int a, int b) { return a/b; }
  • Camino: si consideramos cada bifurcación del código como un nodo, cada camino en el grafo resultante puede ser significativo desde el punto de vista de prueba. El problema es que el número de caminos crece exponencialmente.

  • Cobertura de requerimientos: damos vuelta la métrica, dado que no podemos probar cobertura de código que no existe (tendríamos cobertura mayor que 100%), medimos la cobertura de los requerimientos para ver cuales está implementados. Algo parecido pasa con las API cuando son impuestas (podemos medir si cumplimos con el contratos de las APIs).


¿Cuál es la cobertura correcta? Es como preguntar cuanto dura un día. Puede ser simple (24hs) o complicado.

Nota: no puedo dejar de nombrar la cobertura de XML, que puede ser pensada como un tipo de cobertura de Flujo de datos o de requerimientos.


Coberturas por pruebas de integración

Las pruebas unitarias parten del diseño. Es una forma de diseño ejecutable, gracias a eso nos aseguramos que la aplicación cumpla con el diseño.

¿Pero es correcto el diseño? Por ejemplo, cuando extendemos o nos integramos con productos de terceros, tenemos que validar que nuestra comprensión de esos producto sea correcta y, desde el punto de vista de regresión, que ese comportamiento no haya cambiado en el tiempo.

Estuve en proyectos en los que construíamos addin a MS Outlook, o extensiones a Liferay, y la importancia de estas pruebas era tan grande (por la evaluación de riesgo) que se ponía en dudas la conveniencia de hacer pruebas unitarias. En estos casos, en vez de la pirámide tradicional de automatización de la prueba (mucha unitaria, algo de integración, poco de sistema desde interfase usuaria), se tenía niveles similares de prueba unitaria y de integración.

Si quisieramos medir la cobertura de las pruebas de integración, tendríamos que medir incluyendo al producto plataforma (Outlook o Liferay)


Otras pruebas

Y no todo termina ahí. ¿Hemos probado seguridad, robustez, usabilidad, etc?

¿Son todas las pruebas basadas en ejemplos? ¿Cómo medimos la calidad de la prueba cuando probamos con técnicas que usan oráculos no humanos, invariantes y fuzzing?

¿Hacemos el producto correcto?

Comentamos que en ocaciones necesitamos saber si el diseño es correcto. Pero más importante, ¿hacemos el producto correcto?

Ya sea que hagamos pruebas exploratorias o que tengamos las pruebas de aceptación automatizadas, ¿cómo medimos que estas pruebas sean buenas?


Conclusión

Repitiendo lo que dije al principio, prefiero mil veces discusiones sobre cuánto debemos probar antes que si tenemos o no que probar.
Pero es una discusión que tenemos que tener en el equipo. Y como siempre, la respuesta no es única.

domingo, 23 de agosto de 2009

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).

sábado, 22 de agosto de 2009

Resultados de la charla en Rafaela

El miércoles estuve en Rafaela, Prov. Santa Fé, dando una charla sobre Desarrollo de Software Ágil en UCSE Rafaela.
Rafaela tiene una carrera de ingeniería de software en la UCSE, y una tecnicatura en programación de la UTN, en ambos casos son recientes.
Se está acelerando la cantidad de profesionalesans serifsans serifs del software y las empresas están creciendo en forma acorde.
Aproveché mi visita para visitar algunas de las empresas de software. Rafaela no tiene una gran empresa cliente que defina el mercado, y el mercado local no es muy grande, por lo que las empresas crecen hacia mercados remotos, frecuentemente internacionales.
En ese contexto (más profesionales, empresas creciendo, mercado internacional) varias de las empresas están interesadas en incorporar formas de mantenerse organizadas (crisis de crecimiento) y lograr algún 'sello de calidad'. Siendo empresas chicas, la elección parecería ser Desarrollo ágil + ISO 9001.
En mi presentación traté de indicar las razones por las que se elegiría utilizar desarrollo ágil (y por ende, cuando no), seguido con una introducción a Scrum y una aún más breve para eXtreme Programming, indicando que implementar Scrum sin XP es difícil en el largo plazo.

Hubo 100 personas, lo que superó nuestras expectativas. Muy buena la organización, va mi agradecimiento a Darío Karchesky, las autoridades de UCSE por invitarme, y a todas las personas de UCSE que ayudaron en la organización.

Para los asistentes, si quieren sumarse a la comunidad y ver próximos eventos (además de este blog ;) :

viernes, 14 de agosto de 2009

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!

Desarrollo de Software Ágil en Rafaela

El miércoles 19 estaré en Rafaela, en Universidad Católica de Santiago del Estero, presentando algunas ideas sobre el desarrollo de software:

El Desarrollo del software está en el medio de un proceso de cambio. Luego de estar fuertemente influenciada por estándares surgidos de proyectos enormes del Departamento de Defensa de EEUU (CMMi), desde hace una década se está imponiendo una forma de trabajo, el Desarrollo Ágil de Software, que permiten a las empresas crear productos innovadores de mejor calidad y menor costo. Otra característica importante es que los equipos que trabajan de esta manera están más motivados y contentos con su trabajo. Presentaremos los principios algunas de las metodologías ágiles, Scrum y XP, y veremos como estas metodologías pueden ser implementadas en forma incremental, y conjuntamente con normas ISO 9001.

Más información

Resultados de la charla

miércoles, 12 de agosto de 2009

Registración a Ágiles 2009!

Ya puedes registrate a Ágiles 2009 is open! (evento y cursos)

Ágiles 2009 se realizará los días 6-9 de Octubre en Florianópolis, Brasil.

Ágiles 2009 busca ser el punto de encuentro de los profesionales de TI de latinoamérica interesados en compartir experiencias, discutir y aprender sobre el Desarrollo Ágil de Software.

Entre los invitados internacionales que participarán en Ágiles 2009 están Matt Gelbwaks, Naresh Jain, Dave Nicolette, Joshua Keriewsky y los oradores principales Brian Marick y Diana Larsen.

Lo conferencia consistirá en presentaciones, sesiones interacticas y talleres. Esperamos unas 800 personas de todas partes del mundo.

Antes del evento habrá cursos de CSM, CSPO, TDD y Retrospectivas.

Puedes registrarte en http://www.agiles2009.org/es/registracion.php

Para más información del evento, programa o sede consulta en www.agiles2009.org


Organizadores de Ágiles 2009
Ágiles 2009 es posible gracias a la colaboración de OnCast Technologies y al apoyo de nuestros sponsors:

[Gold Sponsor]
Globo.com
| ThoughtWorks

[Silver Sponsor]
Baufest | Scrum Alliance | Agilar | AdaptWorks | Industrial Logic |
Agile Alliance

[Media Sponsors]
Visão Ágil | InfoQ
| Globalcode

[Institutional Sponsor]
SADIO | ACATE | SUCESU-SC