Domingo, 6 Mayo 2007

El viernes, 4 de mayo, se ha iniciado la segunda y última jornada con nuevas ponencias por la mañana:

  • Rex Black: Five Hard-Won Lessons in Performance, Load, and Reliability Testing
  • Joachim Wegener: A Product Maturity Model for Industrial Practice
  • Marek Kucharski: How to Improve Your Development Process by Automating Infrastructure
  • Luciën Stuivenvolt: Test optimising by ISO

Rex Black: Five Hard-Won Lessons in Performance, Load, and Reliability Testing

Durante la primera sesión de la mañana, Rex Black ha presentado cinco lecciones extraidas de su experiencia en el testeo de rendimiento, carga y fiabilidad. Y es que un problema en alguna de estas áreas puede llevar a las empresas a graves pérdidas, de lo que da algunos ejemplos concretos.

Rex Black, durante la sesión del viernes por la mañana

Las cinco lecciones son las que siguen:

1: Utilizar entornos realistas

En otros campos (diseño de vehículos, de puentes, etc.), los modelos a escala funcionan; pero el software no es lineal, y los modelos reducidos no funcionan tan bien. Es muy importante conocer las diferencias entre el entorno de pruebas y el real, y cómo pueden afectar a los testeos.

2: Usar cargas realistas

Es necesario conocer cómo se comportan realmente los usuarios ante el sistema. Para ello hay que tener en cuenta los diferentes tipos de eventos (periódicos, estacionales, etc.), tipos de usuarios, factores externos, … Rex Black considera útil realizar tests aumentando la carga hasta que el sistema falle, para comprobar si se degrada progresivamente y detectar cuellos de botella.

Los procesos de generación de carga intrusivos (generados por el propio sistema) resultan más útiles en los testeos de carga y fiabilidad. No obstante, para los procesos de testeo de rendimiento es muy aconsejable utilizar generadores no intrusivos (externos), para evitar su interferencia con el propio sistema objeto del testeo.

3: Testear los tests (y los modelos)

Es necesario comprobar que los tests están bien diseñados y que realmente están comprobando el funcionamiento del sistema tal como se desea. Para ello es muy útil crear un modelo del sistema (que puede ir desde una simple hoja de cálculo a una simulación dinámica); de ese modo, se pueden comparar los resultados de los tests y los del modelo para validarlos.

4: Invertir en herramientas (no ser tacaño)

Las herramientas para este tipo de testeo son realmente necesarias, y es importante invertir en ellas. Las herramientas open source pueden ser una opción, aunque teniendo en cuenta que, a pesar de ser gratuitas, su utilización también representa un coste. Eso sí: antes de elegir la herramienta (o herramientas) es importante definir qué necesidades de testeo existen para hacer la mejor elección.

5: Empezar pronto, y continuar durante todo el desarrollo

Es conveniente realizar tests en las primeras etapas de desarrollo y seguir con ellos durante todo el proceso; aunque el sistema no esté implementado, se pueden utilizar modelos y simulaciones. Es un grave error (y frecuente) esperar a que el sistema esté totalmente implementado (y se hayan realizado las pruebas funcionales) para iniciar las pruebas de rendimiento, carga y fiabilidad: un problema detectado en ese momento puede que no se solucione simplemente añadiendo hardware.

Los procesos de testeo en los que se corrigen los cuellos de botella a medida que van apareciendo pueden no ser tampoco una buena idea; es como "pelar una cebolla" por capas… Siempre hay más capas ¡y al final incluso pueden haber lágrimas!.

Joachim Wegener: A Product Maturity Model for Industrial Practice

Joachim Wegener era hasta hace poco empleado de Daimler-Chrysler, y ha expuesto un modelo de madurez de productos aplicado a la industria de fabricación de automóviles (aunque podría aplicarse a otros entornos).

Joachim Wegener, durante su charla

La motivación para usar un modelo de este tipo está provocada por las características del software utilizado: existe en casi todas las áreas de productos; es un factor diferenciación de la competencia; los sistemas son cada vez más complejos; el software es importante en áreas de seguridad; está regulado por múltiples normativas, estándares y regulaciones legales; los fallos tienen costes muy altos…

Crear un modelo a partir del número de defectos es muy difícil, ya que no suelen seguir una tendencia clara y no dan una idea de la calidad del producto. Por tanto, se hace necesario otro tipo de sistema para evaluar dicha calidad.

Sin embargo, los modelos existentes se concentran en el proceso de desarrolllo pero descuidan la evaluación del elemento más importante: el producto final. Por tanto, las predicciones de nivel de madurez habitualmente proporcionan resultados erróneos (por ejemplo, más defectos de los esperados, o que se descubren en fases avanzadas) y provocan riesgos en el proyecto.

Por eso Joachim Wegener expone un modelo de madurez de producto basada en la calidad de diferentes aspectos: del proceso de desarrollo; del hardware; del software (calidad interna); del sistema (calidad externa). De ese modo, se establece un sistema de criterios aplicados a cada aspecto que permiten medir la calidad total del producto, dando a cada criterio un peso determinado.

En el futuro, un modelo de madurez del producto de este tipo ayudará a comparar no sólo diferentes versiones de un producto, sino también productos de diferentes proveedores, proyectos y ámbitos.

Marek Kucharski: How to Improve Your Development Process by Automating Infrastructure

Marek Kucharski ha iniciado su ponencia con una breve presentación de PARASOFT, comentando que desarrollar software debería ser entretenido.

Marek Kucharski, mostrando una demo de la herramienta de seguimiento del desarrollo

Ha expuesto una clasificación de bugs en tres tipos: requerimientos mal implementados (errores); requerimientos ausentes o incompletos; y usuarios confusos usando el sistema de un modo no contemplado. Ya que en la práctica es imposible verificar formalmente que un sistema funcionará correctamente (por su complejidad, por los cambios frecuentes, …), propone utilizar una colección o suite de tests de regresión.

Estos tests de regresión permiten comprobar que los cambios realizados en el software no estropearán la funcionalidad anteriormente existente; se caracterizan porque evolucionan con el código, son fáciles de ejecutar (idealmente de forma automática) e incluyen múltiples tecnologías: monitorización, poor man’s regression test, análisis estático, stream verification.

  • La monitorización: consiste en capturar la interacción real entre la interfaz de la aplicación y la capa de lógica para generar casos de test, usando datos reales.
  • Poor Man’s regression testing: permite crear casos de test automáticamente a partir del código, ejecutarlos y comparar resultados entre ejecuciones cuando cambia el código fuente. No resulta una buena técnica, ya que es difícil identificar los datos que representan el funcionamiento real.
  • Análisis estático: puede estar basado en reglas, comparando el código fuente con determinados patrones, detectando y corrigiendo violaciones de determinadas reglas en el código. O basado en flujos, analizando los posibles caminos en el código fuente y corrigiendo los problemas en su origen.
  • Stream verification: para comprobar la corrección de las comunicaciones entre diferentes módulos.

Estas técnicas pueden ayudar a detectas los diferentes tipos de bugs; pero ¿cómo integrarlas en el proceso de desarrollo? Utilizando informes que irán a los diferentes involucrados (project manager, arquitecto, desarrolladores, testeadores)

Por último, Marek Kucharski ha realizado una pequeña demo online de su herramienta de seguimiento del desarrollo que permite comprobar su estado a partir de los ficheros modificados, desarrolladores, errores encontrados, etc., tanto en modo gráfico como con datos de detalle.

Luciën Stuivenvolt: Test optimising by ISO

Luciën Stuivenvolt, de TestABil, ha narrado durante su charla un caso real de certificación ISO del testeo de software en una empresa holandesa.

Presentación de Luciën Stuivenvolt

¿Por qué un certificado ISO para testeo? Por varios motivos: fue una solicitud de la dirección de la empresa; es un desafío personal para los responsables; la empresa se convierte en un partner certificado. El consejo de Luciën Stuivenvolt es no iniciar un proceso de este tipo hasta que la dirección de la empresa esté realmente interesada.

El proyecto constó de 3 fases, y sus características más importantes es que los plazos y presupuestos estaban claramente delimitados, y que se definió una fecha clara de fin del proyecto. En este punto, el consejo es utilizar la ayuda de expertos en este tipo de proyectos.

Durante el proyecto se realizaron sesiones de equipo, se crearon listas de las actividades existentes y se agruparon dichas actividades. A continuación se compararon con los requerimientos de ISO; la diferencia entre ambos son los "puntos blancos" (white spots) en cada uno de las fases de la rueda de Deming (planificar; realizar; comprobar; actuar) que era necesario rellenar para conseguir el certificado ISO. Estos puntos blancos habitualmente estaban en temas como control de calidad, satisfacción de cliente, etc.

En su realización se utilizarón tres niveles de detalle: el más detallado, con las tareas concretas; el ciclo de control sobre todo el proceso; y la visión general para la dirección.

Finalmente el certificado ISO se consiguió; pero el equipo de testeo sigue evolucionando. Entre otras ventajas, el trabajo realizado permitió la incorporación de nuevos miembros en el equipo sin pérdida de calidad, gracias a la documentación generada.

Deje un comentario

*
Teclea la palabra del recuadro, por favor, para comprobar que eres una persona y no un proceso de spam. << Anti-Spam Image



Blog del grupo SQUaC. ¿Conoces nuestros servicios? testeo de software; etc.

SQUaC, una web del ITI