Modelado de escenarios a partir de logs W3C

Presentamos una nueva técnica para la generación de escenarios para pruebas de performance de aplicaciones y servicios web. La misma se basa en la generación de escenarios realistas del uso del sistema, mediante el procesamiento de los logs obtenidos del servidor de aplicación. Esta técnica permite, por ejemplo, probar diferentes escenarios de expansión de cantidad de usuarios, o ensayar plataformas de hardware alternativas para un sistema.

La simulación está basada en un modelo de Markov de largo variable que se estima a partir de los logs, generando simulaciones que son estadísticamente similares al comportamiento de usuarios reales.

Prerrequisitos

Los prerrequisitos inherentes a la aplicación de esta metodología son:

  1. Disponer de logs en formato W3C de la aplicación por un período que capture satisfactoriamente el uso real de la aplicación, por ejemplo un mes.
  2. Implementar un modelo  de uso realista (RUM del inglés realistic unified model) para las funcionalidades que se desean incluir en la prueba, que permitirá localizar su utilización en los logs.

Generación de escenarios

Contamos con una herramienta web desarrollada en Java/Spring que permite ingresar el modelo RUM y los logs W3C, a partir de los cuales se ejecutarán los procesos de parseo y simulación, obteniendo como resultado un CSV con el guión para la cantidad de usuarios virtuales que se deseen ejecutar. El guión incluirá la lista ordenada de funcionalidades del RUM a invocar, así como los tiempos de espera involucrados en cada transacción.

Ejecución de pruebas

El resultado de la generación de escenarios es independiente de la herramienta que se desee utilizar para ejecutar las pruebas, por lo tanto existe total libertad para escoger la herramienta de testing. La ejecución del guión deberá ser implementada en el lenguaje de scripting utilizado por la herramienta escogida. Se cuenta con un generador de scripts en JMeter que mapea está nueva técnica.

Ventajas de la metodología

La principal ventaja que obtenemos de la aplicación de esta metodología y herramientas es la de generar escenarios realistas que están basados en el uso real de la aplicación.

El proceso de simulación nos asegura que la probabilidad de aparición de cada funcionalidad y el orden en el que éstas aparezcan será estadísticamente representativo del uso que realmente se le da a la aplicación bajo prueba por parte de los usuarios.

Este trabajo es uno de los frutos de una intensa investigación en el marco del proyecto de grado “Modelado y ejecución de pruebas de performance” y años de experiencia en distintas áreas. El proyecto desarrollado por el Ing. Nicolas Diaz y Gabriel Barbartto fue tutoreado por el Dr. Ing. Álvaro Martín, Ing. Gustavo Vázquez e Ing. Gustavo Guimerans.

Gustavo Guimerans

Testing del sistema de escrutinio de la Corte Electoral

Hemos tenido la oportunidad de participar en parte del proceso de pruebas funcionales y de performance del sistema de Escrutinio de la Corte Electoral que se utilizó el pasado 26 de octubre y 30 de noviembre en las Elecciones Nacionales.

Ha significado un nuevo desafío para el equipo del CES. Por una parte, ponernos en contexto sobre un tema que siendo de conocimiento común a toda la población, hay muchas partes del proceso de una instancia de escrutinio que tuvimos que analizar con mayor cuidado. Por otra parte, implica probar el sistema que registra el escrutinio de las Elecciones Nacionales ¡una responsabilidad importantísima y con mucha visibilidad!; en otras palabras, un proyecto sumamente interesante.

Pruebas funcionales

Luego de elaborar el plan de pruebas y realizar el inventario con las funcionalidades, lo discutimos con el equipo de desarrollo de UTE (responsable de la implementación). Para definir la estrategia de las pruebas analizamos los riesgos y el impacto de cada una de las funcionalidades. Para el ingreso de datos y los diferentes cálculos utilizamos testing planificado y para otras funcionalidades de menor prioridad, utilizamos testing exploratorio y documentamos diferentes sesiones según las misiones previamente definidas. Todas estas actividades fueron documentadas debidamente en una plataforma específica quedando a disposición del equipo de desarrollo y testing para futuras consultas.

Pruebas de performance

Para definir las pruebas de performance a ejecutar sobre el sistema se realizó un análisis de la realidad y se seleccionaron las transacciones más utilizadas, así como también la cantidad de usuarios que utilizarían el sistema en base a información histórica de las pasadas elecciones. Por otra parte, se estudió la infraestructura del sistema en lo que respecta a hardware y software (por ejemplo: servidores de aplicación y motores de base de datos) con el objetivo de tener los diferentes componentes controlados y conocer las causas de los eventuales problemas que surgieran.

En base a toda la información recopilada y luego de priorizar las transacciones, se simularon escenarios de prueba correspondientes al 50% y 100% de la carga esperada, en la hora pico de ingresos ponderando por departamento, es decir, se analizó el contexto particular de cada departamento (partidos políticos, listas, votantes, circuitos habilitados, puntos de acceso al sistema habilitados, etc.).

Durante las pruebas se brindó información que permitió mejorar el sistema y corregir los problemas detectados.

La movida del testing

Para empezar el 2014 con toda la fuerza, queremos compartir algunos puntos a tener en cuenta al momento de incluir y/o mejorar el testing en una organización. No es una tarea sencilla y requiere instancias de análisis y otras de tomas de decisiones.

Es importante: pensar, apropiarse, difundir, seleccionar, definir metodología, comunicar, definir un proyecto piloto y mejorar

 

Pensar

Podemos tener la idea en nuestra cabeza de formar un equipo de testing o de contratar servicios de testing independiente. Es  mejor no actuar por impulso designando rápidamente recursos que comiencen a probar. Es probable que no se logren hacer buenas pruebas y que se generen conflictos rápidamente.

Una alternativa es que alguien externo a la organización con conocimiento en testing, proyectos y equipos analice la forma de trabajo y las dificultades que enfrenta la organización y evalúe si formar un solo equipo de testing, varios, o contratar servicios de testing independiente. Además que dimensione los equipos, e indique la capacitación requerida.

Apropiarse

Antes de crear planes de acción, tenemos que estar convencidos de los cambios y de los objetivos que nos proponemos.

La organización tendrá que analizar las propuestas y definir cuales implantar. La idea es que, si bien un actor externo propuso las recomendaciones, la organización las procese, y se convenza y apropie de las mismas.

Difundir

La difusión de los cambios que se vendrán es otra forma de que la organización se apropie de la idea y que cada actor aporte su granito de arena.

Por lo tanto, difundir en la organización la movida en temas relacionados al testing  y cuáles son los objetivos a lograr es un paso que no puede faltar.

Seleccionar

Sea cual sea la decisión, formar un equipo interno o contratar servicios, tenemos que seleccionar quiénes integrarán estos equipos.

Aunque se tercericen los servicios de testing, siempre será necesaria una contraparte dentro de la organización. La contraparte no tiene que tener conocimientos específicos en testing, pero si estar convencida de que con esta movida organizacional se mejorará la calidad de lo producido.

No es una etapa sencilla decidir quiénes formarán parte del equipo. Todos los integrantes tienen que tener conocimientos en testing, y en el corto plazo también conocimiento en el negocio de la organización.

Es usual ver una empresa que forma un equipo de testing con personas sin conocimiento en la materia que prueban sin metodología y a pura intuición, sin priorizar ni preocuparse por el cubrimiento. Claramente la experiencia no colmará las expectativas y sumará nuevos problemas.

Definir metodología

Definir una metodología y forma de trabajo del equipo de testing será el primer proyecto al que se enfrentará el equipo. La metodología no solo incluye aspectos técnicos, sino cómo serán las interacciones con los distintos equipos.

Comunicar

La metodología no pueden ser papeles en un cajón, tiene que impregnarse en la organización para que se aplique. Por lo tanto hay que comunicar la forma de trabajo y metodología propuestos. Someter la metodología a que todos la estudien y opinen es una forma de involucrar a los distintos actores.

Ante los “no tengo tiempo”, es una buena práctica generar reuniones de trabajo eficientes y productivas.

Definir un proyecto piloto

Comenzar de a poco es importante, por ejemplo definiendo un proyecto que sea de dimensiones manejables, en el que el equipo comience trabajando en conjunto y aplicando la metodología.

Mejorar

Por último, aplicar, evaluar y mejorar para continuar aplicando ayudará a alcanzar nuestros objetivos. La metodología y forma de trabajo irá cambiando y mejorando a partir de la experiencia que se va generando.

En próximas entradas del blog les contaremos, a partir de nuestra experiencia, dificultades que se presentan al saltearse algunos de los puntos detallados.

 Mariana Travieso

Testing si o testing no

En muchos clientes que estuve trabajando, escuche la siguiente frase “hacemos testing si o no”. Desde mi punto de vista esta claro, “si, hacemos el testing” pero para mi sorpresa escuchaba “NO hacemos el testing”. Los motivos sobraban, entre los que se escuchaba más habitualmente:

  • es una funcionalidad muy sencilla y es imposible que el desarrollador se equivoque, o
  • no hay tiempo para probarlo en testing lo liberamos a producción porque es urgente,
  • no es necesario porque el cambio es menor.

 

Este es el punto en donde nosotros los “testers” tenemos que hacer hincapié. Incorporar tareas de testing en un proyecto, le da un valor agregado.  Detectar los errores en etapas tempranas, es mucho más beneficioso que detectarlo al final. Participación en las reuniones de relevamiento de requerimientos.

Todos estos puntos ayudan a mejoran la calidad de un producto, por eso cada vez que nos encontremos frente a una situación similar.

 

Testing con humor

Inspirado en Cartoon Tester, dejo un par de cartoons de mi propia mano en los cuales se muestra con humor situaciones que más de alguno ya debe haber experimentado :D

Federico

“Consideraciones para testing en dispositivos móviles”

Estimar y planificar un proyecto de testing requiere de información del propio proyecto de desarrollo y de experiencia en proyectos de similares características. Los proyectos que involucran desarrollo para dispositivos móviles tienen características que los diferencian. En el mapa mental que se muestra se puede observar algunas algunas consideraciones que pueden ser de utilidad al momento de llevar adelante un proyecto de estas características.

El Centro de Ensayos de Software participó en la JIAP el día 15 de Agosto de 2013 con el fin de exponer  información adquirida sobre este tipo de proyectos.

Como podemos apreciar , aspectos como la conectividad, el hardware y el software a utilizar, interrupciones, actualizaciones, experiencia de usuario, almacenamiento, comunicación con otras aplicaciones, clientes, tiempos de ejecución, etc. Son puntos relevantes a la hora de planificar un proyecto de testing para dispositivos móviles.

Agradecemos a todas aquellas personas que nos acompañaron en la charla, e invitamos a aquellas que no se hicieron presentes a ver el material aquí

María Elisa Presto

Martín Sedes

¿Cuánto vale el testing?

Hace unos días me pusieron ante una pregunta que es de las más difíciles que me han hecho en una reunión y además me agarró
totalmente desprevenido: ¿Cuál es el valor de los servicios del CES?

Lo primero que hice fue darle el listado de los precios de los diferentes roles, contándole además que en realidad se debía estimar el proyecto, la dificultad de la tarea a realizar y el tipo de testing. Sin embargo, me dijeron que no lo estaba entendiendo: me preguntaba por el valor y no por el costo. Y tenía razón, hay una clara diferencia entre ambos conceptos. Aunque, sin lugar a dudas, existe una estrecha relación entre ambos.

Poniendo las decisiones en perspectiva
Lo primero que hice fue pensar en un ejemplo. Supongamos que estamos ante el desarrollo de un sistema para un cliente importante. Una de las decisiones antes de comenzar el proyecto será el de evaluar el plan de testing de la aplicación y ver qué tipo de testing y que esfuerzo se dedicaría al mismo (estoy dejando fuera de manera deliberada a aquellos que se cuestionan la realización de t

esting en sí, pero tengamos en cuenta que esa gente también existe, por las dudas).

Si este cliente no tuviera exigencias de calidad en el sistema, posiblemente vería el esfuerzo adicional como un costo que no le aporta nada al proyecto. En ese caso el valor del testing es casi nulo; incluso el precio más bajo que pudiéramos darle para la realización de dicha tarea (incluso aquel precio en el cuál como proveedores podamos perder dinero) le parecerá caro. Pero supongamos que el cliente tenga requerimientos de calidad altos, con un negocio dependiente de lo que estamos desarrollando y en el cuál un error pueda representarle una pérdida de plata directa (ya sea por SLAs no cumplidos, lucro cesante por no disponer del sistema, lo que sea…), seguramente vea esos precios como una inversión y por lo tanto pague nuestros precios sin muchas objeciones.

También existen otros factores que puede darle valor a nuestro trabajo, como por ejemplo, cuanto repercuten los errores en la imagen o reputación del cliente.  Allí ponerle un valor es difícil, quizás la mejor pregunta para hacerse es cuál es el valor máximo que el cliente le da a su imagen, a su reputación. Algo mucho más subjetivo que el dinero, pero que en algunos casos, si bien no representa un costo directo, es importante.

Por defecto, la realidad me ha indicado que el testing no es de las actividades que se tienen en cuenta de planificar. Principalmente estoy convencido de que esto sucede porque no sabemos o no somos capaces de transmitir el valor de las actividades que realizamos. Un valor que nos permita hacer el switch y poder hacer el click en aquellas personas que toman las decisiones. Solo así se logrará que las tareas de testing sean vistas como algo que aporta valor en el sentido más estricto de la palabra.

Luego, atado a eso, vendrán los costos asociados a realizar esa tarea y allí se juega el otro tiempo del partido.

Poniendo precio a nuestro trabajo
El valor que tendrá nuestro trabajo para el cliente será el límite superior que nuestro precio podrá alcanzar. Si lo que nosotros marcamos a nuestro trabajo es mayor que el valor de realizar las actividades de testing, ¿Por qué el cliente se sentirá inclinado a cambiar la decisión de invertir en la calidad del producto?

Claro está que también existe algo que se llama mercado, por lo cual tenemos que tener en cuenta, a la hora de poner precio a nuestro trabajo, que el mismo no puede ser puesto basándose exclusivamente en el valor aportado (lamentablemente no somos Henry Ford vendiendo autos en el 1900, donde Ford vendía el auto del color que quisiera el cliente, siempre que fuera negro). Posiblemente allí le hayamos dejado claro el valor, pero encontrará un costo menor al nuestro para poder alcanzarlo.

Sin embargo, por más apropiado que sean nuestros precios a los del mercado, si no logramos aportar valor al desarrollo de software y por ende al producto, difícilmente alguien firme un cheque para realizar testing. Y es allí donde podemos aportar un diferencial: no necesariamente siendo más baratos, sino siendo los que aportemos más valor.

Nuevas formas de desarrollar => ¿nuevas formas de testear?

Desde hace un tiempo, en el mundo de la informática, las aplicaciones que desarrollamos y usamos, son técnicamente  muy distintas a las antiguas de escritorio.  Estas aplicaciones por lo general interaccionan con otras aplicaciones, por ejemplo utilizan repositorios de datos e invocan servicios externos que podrían estar distribuidos.  La pregunta que nos hacemos hoy es, para las aplicaciones de smartphones (teléfonos inteligentes), comúnmente llamadas apps, ¿se requieren nuevas formas de testear?

apps

Casi todos hemos visto videos en los que se prueban celulares sumergiéndolos en agua, soltándolos en caída libre, tirándolos contra algo para probar ciertas propiedades del hardware, tales como la resistencia de la pantalla, etc.

También existen aplicaciones web para comparar 2 modelos de celulares, incluso de diferentes marcas, se puede evaluar características, comparar funcionalidades, tamaños, etc.  Pero si lo que queremos es probar una app nativa en una versión determinada de un sistema operativo x, en principio surge la interrogante  ¿Qué tipos de prueba es conveniente ejecutar?

sistemas_operativos_smartphones

Durante el desarrollo de cualquier software, el testing unitario es fundamental para obtener información de la calidad del producto. Lo ideal es que el desarrollador ejecute pruebas funcionales en el hardware  en el cual  espera que su app se ejecute, con la versión del  software de base correspondiente. En el testing unitario se prueban las funcionalidades sin interaccionar con otros sistemas, luego  se integra con otros módulos, por ejemplo a través de una API que encapsula los elementos de comunicación  (gmaps, gps, etc.).  Estas primeras pruebas son de caja blanca, y pueden automatizarse por el equipo de desarrollo.

Cuando haya un prototipo o una primera versión de la aplicación se comienzan a ejecutar pruebas de caja negra,  para comprobar que las funcionalidades requeridas existen y se comportan según los requerimientos. En este punto se puede ser tan imaginativo y exigente como se quiera/requiera: revisar pantallas, botones,  flujos de navegación, con/sin conexión a internet, agotando la energía (batería), ciclos funcionales que incluyan llamadas telefónicas y mensajes de texto. Hoy en el mercado el horizonte se amplía muchísimo ya que los distintos modelos de celulares  tienen diferentes pantallas (tradicional/táctil), con varios diseños de botones para utilizar desde la aplicación, diferentes sistemas y versiones de los mismos.

En lo que a seguridad se refiere recomendamos a los analistas y desarrolladores aplicar alguna de las propuestas de buenas prácticas existentes (por ejemplo OWASP), logrando así, desde el comienzo del proyecto un producto “defensivo”, por ejemplo definir y aplicar métodos de protección de datos (archivos temporales,  logs, contraseñas, credenciales). Desarrollar teniendo en mente las debilidades más comunes de las aplicaciones y los fundamentos de una programación segura para prevenir posibles ataques.

Luego un equipo diferente del de desarrollo puede diseñar pruebas para intentar penetrar en la aplicación en busca de posibles vulnerabilidades.

SmartPhoneVirus

Cuando consideremos que la aplicación es estable, y que las funcionalidades hacen lo que se espera, podemos pasar a evaluar nuestra app, desde el punto de vista de su performance. Nuevamente recomendamos que el equipo de desarrollo tenga en mente la performance desde el inicio del proyecto, defina los requerimientos de performance y evalúe módulos y su integración (por ejemplo que el tiempo de respuesta no supere los 3 segundos). En este punto es importante diferenciar el tipo de arquitectura, ya que definirá los tipos de prueba a aplicar. En una arquitectura cliente servidor, será tan importante probar el cliente como el servidor (en el caso del servidor se ejecutan las pruebas usuales para aplicaciones web).  A continuación veremos las particularidades de probar el cliente.

El equipo de testing, teniendo en cuenta los requerimientos definidos  evaluará la performance de la aplicación, agregando puntos de monitorización y llevando al límite la utilización de recursos (GPS, 3G, WiFi) y combinando su ejecución con algunas de las acciones frecuentes al usar un celular, por ejemplo girar el dispositivo, llamadas y mensajes entrantes, aplicaciones que corran en background (esto podría mejorar o empeorar la performance).

En conclusión, tecnológicamente las aplicaciones que usamos están teniendo un giro casi radical y el universo de pruebas posibles se hace cada vez mayor. Sin embargo, los tipos de testing que recomendamos ejecutar son básicamente los mismos, comenzando por un testing de caja blanca (automatizadas o no). Continuando con diferentes pruebas de caja negra preferentemente  diseñadas y ejecutadas por un equipo diferente al de desarrollo.

María Elisa Presto

Curso online “Puertas abiertas al testing” gratis

Para todos aquellos que quieran conocer de qué trata esta apasionante disciplina o conocer cómo el CES concibe esta profesión se publicó Puertas abiertas al testing.

Es un curso que presenta una introducción general sobre el testing y sobre diferentes tipos de pruebas.  Está disponible en la plataforma de capacitación del CES, abierto a todo el mundo.

Los cursos de la Carrera de Testing del CES utilizan la plataforma de la misma forma incorporando además foros, chats, videoconferencias, ejercicios teóricos y con especial énfasis, ejercicios prácticos.

Esperamos que lo recorran y lo disfruten.

Herramientas … en testing de Performance

Al momento de evaluar la performance de un sistema se debe ejercitar el mismo con una determinada carga con el fin de evaluar su desempeño. Si bien se podría invitar a todos los potenciales usuarios del sistema y pedirles que “hagan sus actividades” en el sistema mientras los ingenieros evalúan el comportamiento del mismo, esto en la mayoría de los casos es imposible o tiene muchas desventajas.

 

 

Como mencionamos semanas atrás en una de las charlas, que tuvimos el gusto de compartir en el Testing Day, cuanto más distribuidos están los potenciales usuarios del sistema – más complejo será sincronizar la prueba (momento en que comenzamos la prueba). Y cuantos más sean los usuarios – más costosa será la “prueba” ya que se  tendrá que pagar horas extras a cada una de las personas que vayan a participar de la simulación (seguramente no es viable parar la empresa, es decir las actividades cotidianas para realizar las simulaciones) y se necesitará una estación de trabajo para que esta persona pueda operar con el sistema… el caso en que esta estación de trabajo no sea un simple PC (sino por ejemplo un cajero automático – cómo se vió en un post anterior) también influirá en la cantidad de tiempo que tengo para utilizarlo ya que son horas que tendré que arrendar ese recurso (o no lo tengo disponible para otras actividades).

 

 

Por este motivo es necesario utilizar una herramienta que permita automatizar las distintas acciones que realizan los usuarios en el sistema para luego modelar la realidad de uso del mismo y poder estudiar su comportamiento. Para dicha automatización existen distintas herramientas Open Source y comerciales, que son de utilidad a la hora de hacer una prueba de performance.

 

 

Esta solución a diferencia de las simulaciones con usuarios reales (en vez de virtuales) tiene la ventaja de que es escalable. Es decir, una vez que una máquina capaz de generar carga alcanza su “tope” de cantidad de usuarios y sea necesario generar más carga, se pueden agregar más máquinas y se tiene un potencial para ejecutar cientos de usuarios MÁS. Esto no tiene asociado mayores costos que el tiempo de los responsables asignados para la configuración de la herramienta y la posterior ejecución de cada prueba… En próximos posts intentaremos responder las siguientes preguntas:

¿Por qué es necesaria una prueba de performance?

¿Por qué es necesario utilizar una herramienta?

¿Cómo elegir una herramienta adecuada?

 

Hasta la próxima! saludos.

Gustavo Guimerans