Blog de Antonio Manuel Muñiz

Entradas etiquetadas como as ‘Software Quality’

Sonar PDF Reporter, tu código tiene algo más que decir

3 Febrero 2009 · 5 comentarios

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

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

Categorías: Herramientas · Open Source · Software Quality
Etiquetado: , , , ,

The Agile Quality Concept

16 Diciembre 2008 · 6 comentarios

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.

Categorías: Software Quality
Etiquetado: , , ,

Segundo día en expo:QA

29 Noviembre 2008 · Dejar un comentario

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

Categorías: Software Quality · Testing
Etiquetado: , , ,

Primer día de conferencias en expo:QA

28 Noviembre 2008 · 1 comentario

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.

Categorías: Software Quality · Testing
Etiquetado: , ,

Asistencia al JSWEB

24 Octubre 2008 · Dejar un comentario

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

Categorías: SOA · Software Quality
Etiquetado: , ,