Hace unos días se ha publicado Sonar PDF Plugin 1.0, con una mejora fundamental: el documento PDF se almacena en la base de datos tras cada análisis y puede descargarse desde la GUI de Sonar.

PDF Download from Sonar GUI

También es posible configurar el tipo de reporte desde la interfaz de administración de Sonar:

PDF report type configuration

Se  puede encontrar información más detallada (instalación y uso) en la documentación del proyecto.

Cuando hablamos de calidad del software podemos hacerlo a muchos niveles: rendimiento, mantenibilidad, cumplimiento de requisitos funcionales, estabilidad, proceso de construcción,… y el que en mi opinión constituye la base, el código fuente.

Desde mi punto de vista la calidad del código fuente se extiende hasta otros niveles, por ejemplo, el rendimiento. De hecho, cuando nos disponemos a realizar una auditoría de rendimiento el punto de partida siempre debería ser el código fuente, éste nos puede dar pistas sobre los puntos débiles de la aplicación, los cuales orientarán las pruebas de rendimiento.

Supongamos un caso de uso simple (y muy común): una aplicación web escrita en Java que permite la subida de un fichero a través de un formulario, cuando este stream de datos llega al servidor se carga en memoria y posteriormente se almacena en base de datos. Si tenemos la mala suerte de que al programador se le “olvide” cerrar el stream después de usarlo y por algún motivo esta memoria no sea liberada por el recolector de basura de la JVM, entonces tenemos un problema: ese espacio de memoria no se liberará NUNCA.

La herramienta PMD detecta, entre otras muchas, una mala práctica de programación consistente en no cerrar correctamente los recursos (streams de ficheros, conexiones a bases de datos, etc) después de usarlos. Si la utilizásemos para analizar el código fuente de la aplicación descrita anteriormente nos indicaría que no se está cerrando un recurso. Si lo que buscamos son causas de un problema de memoria en tiempo de ejecución, vamos en el camino correcto. Definiremos una prueba que ejecute el caso de uso en cuestión y la ejecutaremos simulando N usuarios, al mismo tiempo podemos monitorizar el servidor de aplicaciones y verificar que realmente estamos ante un memory leak.

La empresa en la que trabajo (GMV) está apostando con fuerza por el Software Libre, fruto de esta apuesta es la contribución a varios proyectos Open Source, entre ellos Sonar. Cuando se me dió esta oportunidad, no tuve dudas, quería aportar algo a este magnífico proyecto, del cual llevábamos sacando partido bastante tiempo.

Desde hace algún tiempo trabajo (entre otras cosas) para desarrollar un nuevo módulo en Sonar, Sonar PDF Reporter. El objetivo del módulo es añadir una nueva funcionalidad a Sonar que permita la explotación en forma de entregable de gran parte de la información que nos ofrece esta herramienta en su interfaz web.

El módulo genera un archivo PDF que contiene:

• Visión general de la calidad del código de todo el proyecto.
• Información concreta por módulos funcionales: métricas y medidas obtenidas a partir combinaciones de las métricas.
• Información general del proyecto: versionado, estructura de módulos, descripción, etc

Además de ser un módulo integrado en Sonar, durante el diseño siempre tuve en mente el posible uso del módulo de forma independiente, es decir, ofrecer la posibilidad de explotar la información que Sonar proporciona desde nuestra propia aplicación, por ello se ha hecho uso de Web Services API de Sonar.

Sonar PDF Reporter Design

Quedan bastantes retoques y mejoras por realizar, pero puedes descargar un PDF de ejemplo con los reportes del propio proyecto Sonar, y ver en primicia el resultado ;)

Como todo, la calidad del software puede ser entendida y tratada de formas muy diferentes, que en teoría buscan el mismo objetivo. Estoy presenciando personalmente cómo chocan de frente dos enfoques, el ágil y el pesado, pero ¿qué caracteriza a cada uno de estos enfoques?.

Un enfoque pesado se caracteriza por seguir ciertas normas predefinidas y comunes para todos los proyectos, independientemente de la naturaleza de los mismos. En mi opinión, un enfoque ágil debe aportar valor en los aspectos que realmente son importantes para cada proyecto concreto.

Enfoque “ágil” de la calidad

• Filosofía de aporte de valor. Como comentaba antes el aporte de valor a los aspectos realmente importantes de cada proyecto es la base de un enfoque ágil. No existen unas normas perfectamente definidas en un libro de 300 páginas, la norma es: si aporta valor al equipo de proyecto y al cliente, se hace (siempre dentro de los límites económicos del proyecto, porque como sabemos, la calidad cuesta dinero).
• Documentación útil. La documentación es una tarea que consume mucho tiempo, y por tanto hay que dosificarla. Solamente se generará la documentación que realmente sea útil durante el desarollo y mantenimiento del proyecto, no tiene sentido la redacción de pesados documentos que en el mejor de los casos acaban en el cajón del cliente sin haber sido leídos. Es fundamental mantener la documentación, ya que es un entregable que evoluciona al mismo ritmo que el desarrollo en una metodología ágil, la perdida de coherencia en la documentación puede ser una gran fuente de errores (y por tanto de trabajo extra).
• Software que funciona. Una medida de calidad será el software que funciona, y además funciona reflejando el catálogo de requisitos en la implementación, y por supuesto, siendo la implementación correcta a nivel técnico. La piedra angular para asegurar estos dos aspectos es el testing. Si se consigue todo lo anterior, posiblemente otra medida de calidad será la enhorabuena del cliente.
• Calidad del código fuente. Este es uno de los aspectos que más se dejan de lado en las metodologías pesadas. Cuando uno se enfrenta a un proyecto cuyo código es de calidad, las cosas son más fáciles. La calidad del código comprende aspectos como el seguimiento de una guía de estilo y codificación, evitar el uso de formas de programación que pueden provocar errores potenciales, mantener un código usable, legible, extendible, eficiente, portable y correctamente versionado para su posterior mantenimiento.
• Integración continua. En un enfoque ágil del aseguramiento de la calidad no puede faltar un sistema de integración continua. Con él automatizaremos las pruebas definidas para el proyecto, compilaremos el código integrando los cambios efectuados por lo desarrolladores, generaremos documentación periodicamente que puede ser consultada incluso por el cliente y mantendremos el código sano en todos los sentidos.

En mi opinión estos son los puntos fundamentales de un enfoque ágil del aseguramiento de la calidad.

El segundo (y último) día de conferencias en expo:QA, al igual que el primero, no me ha defraudado. Me vuelvo a Sevilla muy satisfecho. De las conferencias de hoy destaco dos:

Integración Continua (Eric Pugh, Open Source Connections)

Eric Pugh nos ha contado cómo implantar un sistema de integración continua teniendo en cuenta los contratiempos que encontraremos (tanto técnicos como “sociales”), entendiendo como contratienpos sociales por ejemplo el hecho de que los programadores vean el sistema de IC como una herramienta que sólo resalta los errores que se cometen, cuando en realidad es todo lo contrario, les ayuda a realizar mejor su trabajo. Incluso les ahorra tiempo cuando hay que preparar una demo al cliente, todo se reduce a lanzar un build en IC.

Eric comentaba que la IC será un “radiador de información útil para todo el equipo del proyecto”. Por último vimos una demostración con Hudson. Destacar el esfuerzo de Eric por hacer la exposición en español.

Methodology for performace testing (Edgardo Greising)

En esta charla Edgardo ha compartido la metodología usada en el laboratorio de Ensayos de Plataformas del CES. Esta metodología consiste en:

• Definición de escenarios: infraestructura, datos de prueba, número de usuarios concurrentes, etc
• Automatización: determinar el guión de ejecución
• Reproducción del entorno de producción: hardware, software, red (en caso de que queramos medir tiempos)
• Monitorización: a nivel software y a nivel humano (usuarios reales interactuando con la aplicación en paralelo con cientos de usuarios virtuales)
• Reportes: recomendando el uso de gráficas para encontrar patrones de comportamiento

Una vez finalizado el primer día de conferencias en expo:QA me deja un buen sabor de boca, y ganas de escuchar lo que viene mañana. En general las conferencias están siendo bastante interesantes, y lo que más me gusta, lo que se cuenta aquí está en la línea que seguimos en la empresa en la que trabajo, con más o menos dificultades ;).

Algunas reseñas de las conferencias más destacables de hoy (en mi opinión, por suspuesto):

Cualificaciones del ingeniero de pruebas basadas en la competencia: ¿el siguiente paso para la profesión del ingeniero de pruebas?

En esta conferencia Susan Windsor hablaba de los pros y contras de las recientes certificaciones de Software Testing, destacando cómo alguien que no tiene ninguna experiencia técnica en testeo de software puede aprobar la certificación simplemente estudiando un determinado glosario y unas nociones básicas. Por contra, la obtención de la certificación hace que todos los profesionales certificados usen un lenguaje común al hablar de software testing y unas metodologías similares que aunan esfuerzos a la hora de definir las pruebas. Por otro lado pasaba a valorar las cualidades necesarias para ser un buen tester, tanto innatas, como adquiridas.

Evitar el síndrome de caja negra en proyectos de software externalizados

Luis Rodríguez Berzosa ha realizado una charla muy interesante, orientada al aseguramiento de la calidad en proyectos (o partes de proyectos) que se externalizan bajo el lema toma requisitos y dame software, valorando las implicaciones que tiene la no gestión de la calidad del software externalizado. Me gustó especialmente la frase “cuando mejor se reconoce la falta de calidad es cuando se sufre”, y en este tipo de desarrollos la empresa receptora del software es la que lo sufre, es decir, la que lo mantiene, lo migra, lo modifica, etc. En este aspecto, comentaba Luis, es importante medir una serie de factores (métricas) como son: Fiabilidad, Usabilidad, Eficiencia, Comprensibilidad (legibilidad del código) y facilidad de migración (esto lo digo yo: estas métricas me suenan). Otra frase destacable, en cuanto al seguimiento de determinadas normas o metodologías (ISO, CMMI, etc): “El talento supuesto no es suficiente se necesita buen trabajo”, en relación a la tendencia de las normas de decir qué, pero no cómo.

Gestión de la calidad en los diferentes roles

En esta charla he visto cómo el concepto de Ecosistema Software también esta presente en Microsoft, por supuesto en un entorno .NET. Luis Fraile nos ha contado cómo modela microsoft las tareas de cada rol en un equipo de desarrollo, desde el jefe de proyecto (con el paquete office, integrado en el ecosistema) hasta el desarrollador y el QA (con Visual Studio), todo ello enmarcado en la plataforma de desarrollo Visual Studio Team System. En mi opinión tiene un pequeño hueco en el rol de analista funcional, ya que no hay ninguna herramienta en el “ecosistema” que modele las tareas del analista, y mucho menos que las trace hacia las tareas del resto del equipo.

Eso es todo por hoy, mañana más.

La semana que viene acudiré al JSWEB. Por desgracia no hemos podido presentar nada, el año que viene no se nos escapa.

Estoy preparando un post sobre procesos de aseguramiento de la calidad asociados al desarrollo de servicios web, espero tenerlo pronto ;)

Si no cuidamos las dependencias transitivas de nuestros proyectos web modelados con Maven, podemos encontrarnos con el problema de que nuestro WAR alcance un tamaño desproporcionado (hablamos de 40 o 50 MB), evidentemente, esto no es lógico. Está claro que estamos incluyendo decenas de librerías que no son usadas.

En los últimos días he estado llevando a cabo la tarea de “limpiar” las dependencias de uno de los proyectos en los que estoy trabajando. Me he encontrado cosas muy curiosas, como artefactos que dependen transitivamente de versiones anteriores de si mismas (jaxen:jaxen:1.1-beta6 -> jdom:jdom 1.0 -> jaxen:jaxen:1.0FCS), o ver que hay hasta 6 versiones distintas de log4j y 3 de spring-core en el classpath (con los consiguientes errores en los tests que acarrea esta última).

Para evitar esto debemos realizar un estudio a fondo de las dependencias del proyecto y poner los exclude necesarios en el POM. Esta tarea es prácticamente imposible si no se dispone de algún tipo de herramienta que analice por nosotros el POM obteniendo un listado de dependencias (directas y transitivas).

Mi primera opción ha sido una pequeña aplicación Java de escritorio: Maven Dependency Browser. En la propia página de esta herramienta se lee que ya no está siendo evolucionada, debido a que ha sido incluida como parte del proyecto Q4E y se mantiene de forma conjunta.

Q4E es un plugin para Eclipse que integra el uso de Maven con el IDE. Además incluye algunas herramientas como el citado Maven Dependency Browser, pero la funcionalidad que más me ha sorprendido es Maven Dependency Viewer, y como muestra un botón:

Se trata del grafo de dependencias del módulo sonar-web del proyecto Sonar. Evidentemente, así es más fácil trabajar.

Cuando se usan frameworks Javascript, como ExtJS o YUI, en la capa de presentación de una aplicación web nuestro navegador debe descargar todo el Javascript antes de poder mostrar nada. Esto se traduce en un tiempo de espera, por parte del usuario, en ocasiones demasiado largo. Una medida, como otras muchas, de calidad del software, es la satisfacción del usuario final en cuanto a rendimiento de la aplicación, y por tanto debe ser tenida en cuenta durante el proceso de SQA.

Una solución a este problema es la aplicación conjunta de dos métodos: compresión/ofuscado (minify) y uso de un solo fichero que contiene todo el Javascript. De esta forma el navegador sólo debe hacer una llamada para descargar un fichero comprimido, y no decenas de llamadas para descargar cada pequeño fichero Javascript (sin comprimir).

Este proceso puede hacerse a mano, usando herramientas como YUI Compressor, o automatizarlo durante el ciclo de vida de nuestro proyecto Maven. El plugin Maven YUI Compressor hace uso de la herramienta citada anteriormente para integrar este proceso durante el empaquetado de la aplicación web.

La configuración que requiere el plugin en el pom es la siguiente:

<plugins>
    <plugin>
        <groupId>net.sf.alchim</groupId>
        <artifactId>yuicompressor-maven-plugin</artifactId>
        <version>0.7.1</version>
        <executions>
            <execution>
                <goals>
                    <goal>compress</goal>
                </goals>
                <phase>generate-sources</phase>
            </execution>
        </executions>
        <configuration>
            <nosuffix>false</nosuffix>
            <jswarn>false</jswarn>
            <preserveStringLiterals>true</preserveStringLiterals>
            <preserveAllSemiColons>true</preserveAllSemiColons>
            <nomunge>true</nomunge>
            <failOnWarning>false</failOnWarning>
            <sourceDirectory>${basedir}/src/main/webapp/public</sourceDirectory>
            <outputDirectory>${project.build.directory}/compressed/public</outputDirectory>
            <aggregations>
                <aggregation>
                    <includes>
                        <include>**/*-min.js</include>
                    </includes>
                    <output>
${project.build.directory}/${project.artifactId}-${project.version}/public/scripts/todo-el-javascript.js
                    </output>
                </aggregation>
            </aggregations>
        </configuration>
    </plugin>
</plugins>

Esta configuración realizará las siguientes tareas:

1. Comprimir/ofuscar (minify) cada fichero Javascript generando un fichero [nombre_original]-min.js
2. Colocar el código comprimido en target/compressed/public
3. Unir todos los ficheros ofuscados (*-min.js) en uno: todo-el-javascript.js
4. Colocarlo en target/[artifact]-[version]/public/scripts

En el proyecto que he usado como ejemplo se ha conseguido reducir en un 40% el tamaño total en bytes del código Javascript que el navegador debe descargar, a esto hay que sumarle la ganacia en tiempo que se produce al descargar un solo fichero con una sola petición.

Este plugin además ofrece otra funcionalidad, el análisis estático del código usando Jslint, pero esto será tratado en otra entrada futura ;)

Como comenté hace unos días (en el post anterior) he configurado Maven Dashboard Report Plugin para un proyecto Open Source que conozco de cerca, Opina: gestor de encuestas. La versión 2 de esta aplicación está compuesta por dos módulos (por ahora) y está en una fase temprana de su implementación.

La configuración no es compleja, basta seguir la documentación publicada en la propia página del plugin, la única peculiaridad es que, como he comentado, Opina está compuesto de varios módulos Maven, para ello también hay documentación en la página oficial.

El resultado ha sido el siguiente. Para el módulo opina-model:

Para el módulo opina-dao:

Y lo que más me gusta, un resumen que agrupa a todos módulos:

]]> http://amunizmartin.wordpress.com/2008/09/18/recopilando-la-informacion-ii-maven-dashboard-report-plugin/feed/ 3 Antonio Manuel Muñiz Martín findbugs-model findbugs-model-priority cobertura-model surefire-dao cobertura-dao findbugs-opina findbugs-opina-priority http://amunizmartin.wordpress.com/2008/07/23/exploratory-testing-tests-al-vuelo/ http://amunizmartin.wordpress.com/2008/07/23/exploratory-testing-tests-al-vuelo/#comments Tue, 22 Jul 2008 22:09:51 +0000 Antonio Manuel Muñiz Martín http://amunizmartin.wordpress.com/?p=37 ]]>

El concepto de Exploratory Testing se adapta a la perfección al tipo de tests requeridos si se sigue una metodología ágil en el desarrollo de software.

El exploratory testing, como su nombre indica, consiste en la aplicación de un enfoque exploratorio y medianamente superficial a la definición pruebas, en contraposición al testing “profundo” o “tradicional”, que se centra en una funcionalidad y la prueba exhaustivamente mediante pesados scripts o planes de pruebas.

En concreto se trata de indentificar a grandes rasgos los principales módulos funcionales de la aplicación a probar, definiendo una serie de pruebas que no entran en detalles ni casos que se prevé que serán poco usados. De esta forma se puede definir todo un conjunto se tests que cubren gran parte de la funcionalidad básica de la aplicación.

La ventaja del exploratory testing, además de ser más ameno para el tester que el testing “profundo”, es que de una forma temprana podemos obtener un conjunto de pruebas que abarcan todo el sistema desarrollado, de esta forma se encuentran bugs de forma rápida y temprana. Este enfoque es aplicable a proyectos cuyos requisitos no son completos desde el instante 0, ya que los tests se centran en los requisitos de más alto nivel, que generalmente no cambian a lo largo del desarrollo.

Evidentemente también hay contras. El principal inconveniente es que la cobertura de código cae en picado, con el consecuente riesgo de dejar de lado problemas potenciales de la aplicación que pueden surgir en fases más tardías.

Decía al comienzo que el exploratory testing se adapta a la perfección a una metodología ágil de desarrollo de software, el enfoque es claro, podemos reducir el tiempo de definición y ejecución de pruebas, pudiendo realizar una prueba completa de la aplicación en cada iteración o hito del proyeto, podemos adaptar el plan de pruebas a los requisitos que cambien en cada hito de forma sencilla. Al ahorrar tiempo (y dinero) en las fases anteriores, el equipo de calidad puede dedicarse a preparar un buen plan de implantación lo más sencillo y automatizado posible (por ejemplo).

Como decía Aristóteles, “en el término medio esta la virtud”, por eso la realidad (al menos lo que vivo día a día) es que lo óptimo viene a ser una mezcla sutil de ambos enfoques, el pesado y el exploratorio, consiguiendo un equilibrio entre formalidad y agilidad.

La calidad del software es un concepto en ocasiones algo abstracto. Qué mejor forma de concretar
un idea que con números. Seguramente todos hemos escuchado la famosa frase de Tom DeMarco: “no
podemos controlar lo que no podemos medir“, pues bien, Sonar nos da una herramienta de medición bastante completa, y por tanto, control.

Llaman la atención especialmente medidas como la mantenibilidad o la eficiencia del código.

Por otro lado su utilización es bastante sencilla, basta con deplegar nuestro proyecto modelado con
Maven ejecutando:

mvn org.codehaus.sonar:sonar-maven-plugin:1.2:sonar

Este aspecto ofrece la posibilidad de integrar Sonar con nuestro sistema de integración contínua, solo hay que definir este “build” además de los que tuviéramos definidos previamente y periódicamente se realizará un analisis estático del código del que obtendremos métricas muy interesantes.

He encontrado un blog magnífico, sofware-quality, en él he leido una entrada en la que se hace referencia a un artículo de Linda Hayes. En el artículo se expone que la productividad y la calidad del producto software generado por un equipo numeroso de personas es menor que la de un producto generado por un equipo reducido de personas.

Creo que esto es totalmente cierto. Pero tabién es cierto que existen formas de conseguir que un equipo amplio se coordine, que parte del equipo de desarrollo se dedique a sub-componentes del sistema, y a cada uno de éstos se le apliquen herramientas que permitan asegurar la calidad del producto final. Las palabras adecuadas son… integración continua.