Blog de Antonio Manuel Muñiz

Desarrollo, Ingeniería y Calidad del Software

Archivos en la Categoría: Testing

Segundo día en expo:QA

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
Anuncios

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.

Load testing con Tsung

Tsung es una herramienta Open Source para realizar pruebas de carga de varios tipos: HTTP, WebDAV, XMPP (Jabber), PostgreSQL, MySQL y LDAP. Hasta ahora había usado JMeter para definir pruebas de carga sobre aplicaciones web, mediante la repetición controlada de peticiones HTTP más o menos complejas. Realmente lo que me ha sorprendido de Tsung es la variedad de tipos de tests posibles, especialmente las pruebas sobre bases de datos (MySQL y PostgreSQL) y sobre protocolo WebDAV.

Es cierto que la usabilidad de Tsung no está al nivel de JMeter, principalmente porque no tiene interfaz gráfica, pero el resultado en cuanto a interpretación de los reportes de la prueba, no tiene nada que envidiar, incluso diría que supera a JMeter en este aspecto.

Para realizar una prueba con Tsung el procedimiento es el siguiente (para una prueba a un servidor WebDAV, por ejemplo).

En primer lugar debemos instalar Tsung. Existen distrubuciones binarias para Debian, Ubuntu y RedHat, aunque para los amantes de la compilación existe una distribución de código fuente.

Para capturar las peticiones al servidor lanzamos el recorder:

~/Antonio$ tsung -p webdav recorder

Realizamos las peticiones configurando un proxy (localhost:8090, por defecto) en la herramienta que usemos para realizar las peticion (algún cliente WebDAV). Tsung generará un fichero XML que incrustaremos en el fichero de configuración ($HOME/.tsung/tsung.xml), en su sección sessions. En el fichero tsung.xml configuramos también los parámetros de la prueba: número de usuarios (simulados) concurrentes, intervalo entre peticiones, etc. Una caracteristica que llama la atención de Tsung es la posibilidad de configurar cierta incertidumbre en la prueba, por ejemplo, podemos indicar que simule peticiones desde un cliente X con una probabilidad del 80% y desde un cliente Y con un 20%. Incluso podemos definir incertidumbre en la propia petición (en tsung, sesiones).

Una vez configurada la prueba, lanzamos el test:

~/Antonio$ tsung -p webdav start

Al comienzo del test Tsung crea un directorio en $HOME/.tsung/log en el que escribe los ficheros de reporte. Estos ficheros serán tratados posteriormente para generar HTML con la información, esta tarea se lleva a cabo mediante el script tsung_stats.pl, incluido en la distribución de Tsung. Para poder visualizar el resultado de los tests en tiempo real podemos preparar un pequeño script que llame reiteradamente a tsung_stats.pl:

#!/bin/sh
alias tsung_stats='/usr/lib/tsung/bin/tsung_stats.pl'
tsung_stats
firefox ./graph.html
while [ "true" ]
do
  echo "Refreshing stats..."
  tsung_stats
  sleep 3
done

Este script se debe llamar desde el directorio en el que Tsung genera los reportes. Genera los HTML cada 3 segundos, lo único que debemos hacer es refrescar Firefox para ver la evolución.

tsung-graph-report

Estrategias de integración continua

Desde mi punto de vista las tareas de integración continua en un proyecto deben seguir estrategias diferentes en función del momento en que se encuentre el proyecto.

En fases tempranas del desarrollo los tests suelen fallar, porque el test no es totalmente estable, porque los desarrolladores han modificado algo que afecta a algún test, o simplemente porque en estas fases se producen cambios de rumbo más o menos importantes en cuanto a desarrollo. En esta fase temprana nos interesa que la integración continua genere reportes y documentación con una frecuencia alta (por ejemplo, cada hora) de forma que pueda consultarse el estado de las pruebas, pero que solo “avise” (fallo en una tarea) cuando falla la compilación, y no cuando fallan las pruebas. Es normal que las pruebas fallen, están para eso, si no fallaran nunca no tendrían sentido (o estamos dejando pruebas en el tintero).

Ahora bien, una vez alcanzado aproximadamente el 60% del tiempo total del proyecto se supone que la aplicación es bastante estable y las pruebas deben satisfacerse con pulcritud, ya no es aceptable que se produzcan fallos, y si se producen, debe ser motivo de alerta. En este punto la estrategia de integración continua debe cambiar, la frecuencia de ejecución de pruebas y generación de reportes puede disminuir (por ejemplo, cada noche), la compilación debe mantenerse cada hora, y si una prueba falla sí debe generarse un error en integración continua y notificarlo debidamente.

Exploratory Testing: tests al vuelo

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.