Primer día de conferencias en expo:QA

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.

Asistencia al JSWEB

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

Q4E Dependency Viewer: Maven y las dependencias transitivas

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.

Minimizando el tiempo de carga: Maven YUI Compressor

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

Recopilando la información (II): Maven Dashboard Report Plugin

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: