Quantcast
Channel: Abstracta Blog
Viewing all 48 articles
Browse latest View live
↧

Simulacros de puesta en producción

May 11, 2015, 3:49 pm
$
0
0
En las últimas semanas se puso en producción una nueva versión de un sistema desarrollado en GeneXus que venimos probando desde octubre, el cual sufrió cambios muy importantes, con lo cual el trabajo de revisión y verificación realizado fue muy intenso.

Aparte de la metodología, técnicas, gestión de casos de prueba y de incidentes, los aspectos de comunicación y el buen trabajo que se logró gracias a la sinergia con el equipo de desarrollo, quiero destacar una práctica que llevamos adelante que resultó muy valiosa al anticipar y prevenir algunos problemas: simulacro de puesta en producción.


Básicamente se planteó hacer la puesta en producción en el equipo de testing, incluyendo:
  • bajar el sistema, desconectando a todo el mundo del equipo,
  • migrar los programas,
  • migrar los datos (esto ya se había hecho con anterioridad, pero es fundamental para estimar el tiempo que lleva esta tarea, y ver si en la noche se puede completar),
  • configurar todo lo necesario,
  • ejecutar los procesos de inicialización del sistema (como un día normal de la operativa),
  • ejecutar pruebas con testers (ciclo crítico, dos horas en total),
  • ejecutar pruebas con usuarios, tomando a usuarios claves de cada sector, y habiendo hecho un adecuado análisis de riesgos (por ejemplo, la parte de ventas era la que más se tenía que probar),
  • ejecutar los procesos de cierre del sistema (tareas que se ejecutan al final de cada día).
Es fundamental usar esta instancia como un aprendizaje, tomar nota de todo lo realizado y estar atento a los posibles riesgos no identificados previamente, y a las oportunidades de mejora del proceso de puesta en producción.

Se detectaron varios incidentes importantes, pero ninguno de difícil resolución, ya que el testing realizado previamente había detectado los incidentes más importantes con antelación.

Seguro que muchos ya han realizado este tipo de prácticas y ven claros los beneficios, pero quería destacarlo para los que no han tenido la oportunidad. El proyecto fue todo un éxito, ya que no sucedió nada grave que bloquee la operativa del cliente, y considero que esta práctica fue clave también en este resultado.
↧
Search

¿Un bug puede convertirse en una feature?

May 13, 2015, 12:49 pm
$
0
0
Alguna vez escuché esto como chiste, pero hace poco lo escuché en una situación real. Por un bug del sistema en parte, y por uso de los usuarios por otro.


El sistema en cuestión no controlaba que la entrada en cierto campo sea válida, entonces, por falta de entendimiento de los usuarios, estos estaban ingresando otro valor que no tenía nada que ver. El tema es que ese valor ingresado en ese campo luego se terminó volviendo fundamental para la operativa, ya que las búsquedas se realizaban sobre este mismo campo.

Lo gracioso del asunto es que cuando se corrige esto, los usuarios se quejan del cambio y piden que vuelva a estar como estaba antes. O sea, ¡reportan un incidente pidiendo que vuelvan a ingresar el incidente que estaba antes!
↧
↧

Comentarios sobre PhantomJS y GhostDriver

May 15, 2015, 9:59 am
$
0
0
PhantomJS se integra con Selenium a través de GhostDriver. GhostDriver es una implementación de WebDriver Wire Protocol para PhantomJS como mismo lo es ChromeDriver para el Chrome.



Ventajas de Selenium con PhantomJS

  1. El resultado de las pruebas se obtienen mucho mas rápido. Como ya comentamos en antes, se puede acelerar la ejecución de pruebas automáticas Web con PhantomJS. Puede llegar a disminuir el tiempo de ejecución de las pruebas a la mitad o mas, según el driver de Selenium que se utilice para la comparación. En nuestras pruebas lo redujo un 40%.
  2. Es muy fácil de configurar. 

Desventajas de Selenium con PhantomJS

  1. No es un navegador real. Esto trae como consecuencia que no da la seguridad al 100% que se comporte como un navegador real. 
  2. La implementación de las pruebas se hace mas compleja al acceder a los elementos html.
  3. PhantomJS no usa el mismo motor javaScript que usa Chrome o FireFox.
  4. PhantomJS es usado por importantes compañías como Twitter para pruebas unitarias, LinkedIn para pruebas de rendimiento, pero con Selenium para pruebas funcionales no existen experiencias significativas.
  5. Su tiempo de uso es de solo 4 años.
  6. Tiene varios bugs reportados con pruebas que funcionan para FireFoxDriver y no para GhostDriver como las pruebas a los componentes de valores despegables, drag and drop y multimedia.

Aunque el tiempo de ejecución de las pruebas disminuye significativamente aumenta el riesgo de que las pruebas automatizadas no tengan el comportamiento esperado. Habrá que analizarlo en cada caso.
Esto fue una investigación inicial la cual queremos profundizar con el uso real.

Este post lo agradezco a Abel, uno de los valores cubanos con los que contamos, quien hizo la investigación y pruebas.

Algunas referencias:

  • http://cdn.ivandemarino.me/slides/speed_up_selenium_with_phantomjs/index.html
  • http://www.chrisle.me/2013/08/5-reasons-i-chose-selenium-over-phantomjs/
  • http://phantomjs.org/users.html
  • https://github.com/detro/ghostdriver
  • https://code.google.com/p/selenium/issues/detail?id=8088
  • https://github.com/ariya/phantomjs/issues
  • https://www.youtube.com/watch?v=wqxkKIC2HDY
  • https://www.youtube.com/watch?v=bMWYbv7g644


↧

Diseñar las pruebas de performance con un poco de futurología

May 29, 2015, 1:06 pm
$
0
0
Al momento de diseñar pruebas de performance, específicamente una prueba de carga (para ver los distintos tipos de pruebas leer acá) debemos simular lo más fielmente la realidad a la que se enfrentará el sistema, para de esa forma poder reducir los riesgos de la puesta en producción.

Para poder hacer este diseño generalmente se tienen entrevistas con analistas, expertos del negocio, desarrolladores, encargados de infraestructura, etc. Muchas veces uno se apoya en estadísticas de uso (analizando los access log del sistema si ya está en producción). Con esta información generalmente se obtiene la carga que el sistema tiene hoy en día, y se busca cuáles son los momentos de mayor estrés para intentar simularlos.

Hemos visto en algún caso la necesidad e importancia de guiar al entrevistado a pensar no solo en la situación presente, sino de pensar en el futuro también. Es necesario resaltar al hacer el diseño de las pruebas de performance que estas deberían apuntar a futuro, o sea, no solo basarse en logs de acceso, sino apuntar a la carga proyectada.

Un gerente lee un informe y dice "ok, con la carga que simularon el sistema parece no tener problemas para soportar eficazmente lo del mes pasado... pero qué pasa si hago una campaña de marketing y duplico las visitas al sitio?".



En ciertas situaciones se establece directamente la carga del 100% como la carga que se proyecta a futuro, como por ejemplo en un proyecto reciente hicimos esto considerando la carga estimada para dentro de 5 años. 

Otra forma es definir nuestro escenario del 100% como el 100% actual de producción al día de hoy, y luego apuntar a ejecutar una prueba del 110% o del 150%, según se estime crecer. 

Esto afecta claramente la estimación de esfuerzo de la prueba. Cuando estimamos el tiempo destinado a las ejecuciones en general lo hacemos pensando en llegar hasta el 100% de la carga, y "si sobra tiempo" ejecutamos con más carga. Sería deseable incluir en el tiempo de ejecuciones del cronograma las pruebas del 150%, 200% de la carga actual, de acuerdo a las proyecciones que existan. 


¿Cómo hacemos para conocer la carga proyectada?
Esta es una de las dificultades, la estimación de crecimiento, y se puede hacer analizando el histórico de crecimiento, o involucrando gente de marketing de la empresa por ejemplo, que son quienes tienen claro el objetivo de crecimiento y proponen estrategias para alcanzarlo. 

Otra de las grandes dificultades de estas pruebas suele estar en la base de datos utilizada. Si por ejemplo definimos la carga como la actividad de los usuarios 3 años más adelante, contemplando el crecimiento esperado, pero el volumen de datos de la base de datos utilizada en las pruebas no contiene el histórico que se generaría en 3 años de uso del sistema, no estaremos simulando la situación completa a la que estará expuesto el servidor. 

Se debe tener en cuenta la tarea de generar esos datos, o sino dejar claro que la prueba no contempla esta particularidad, con lo cual queda cierto grado de incertidumbre, pero como siempre, uno apunta a maximizar la relación de costo/beneficio, con lo cual, si el costo de generar esos datos es muy alto, es preferible no hacerlo. 


Claro está que teniendo tiempo y recursos, lo ideal es apuntar a conocer cuál es el límite superior, independiente de las expectativas futuras del cliente, simplemente para documentar cuál es el punto de quiebre del sistema, o para descubrir potenciales problemas de antemano. 


↧

Encontrando problemas en producción con Microsoft IntelliTrace

June 1, 2015, 11:09 am
$
0
0
En un proyecto de ingeniería de performance típicamente un cliente tiene un problema de performance en producción y necesita hacer trabajar en conjunto a todos sus diferentes especialistas (base de datos, sistema operativo, desarrolladores, etc.) para encontrar la solución.

Describiéndolo en alto nivel se podría decir que se tienen un conjunto de síntomas (siempre parecen aleatorios y sin causa aparente) para los cuales se tiene que establecer cuáles son las causas. En la interna le llamamos jugar al doctor House:


Son de los proyectos más entretenidos que tenemos. Son urgentes y desafiantes. Se tienen un conjunto de herramientas y metodologías muy ligadas al mundo de los DevOps.

En este caso en particular lo que teníamos era una aplicación web para la cual todo funcionaba bien en un servidor, pero cuando se la llevó a otro servidor "exactamente igual" los usuarios inesperadamente perdían la sesión, con lo cual la aplicación los redirigía hacia el login.

Una de las herramientas que nos ayudó a entender internamente qué era lo que sucedía fue IntelliTrace. En particular utilizamos "IntelliTrace stand-alone collector" siguiendo los pasos mencionados aquí.

Como los usuarios ya estaban ejecutando en el servidor que funcionaba, prendimos el perfil trace y ejecutamos en el navegador hasta reproducir el problema. Esto nos generó un archivo de 256 MB con mucha información útil. En particular nos permite hacer playback de cada cosa que pasó desde que llegó un request, qué código ejecutó, resumir qué eventos pasaron (excepciones, accesos a la BD, etc., etc.).

En particular lo que nos fue muy útil fue ver la sesión que le asignaba a cada request. Con esto vimos que en el pedido que fallaba se asignaba una sesión diferente (por más que el cliente envíe el mismo identificador de sessión asp_sessionid). Luego de investigar un poco más llegamos a que el culpable de este tema fuera ........ ¡el antivirus!

Si bien no se veía ningún evento en el servidor ni en el antivirus que nos guiaran hacia él, luego de desinstalarlo todo quedó solucionado.

Tal como pasa en los problemas de matemática, una vez que uno conoce la solución el problema parece muy obvio, pero les aseguro que la demostración fue todo un desafío.

¿Alguien más ha probado el IntelliTrace? ¿Qué uso le dieron?
Algunas dudas que tenemos en Abstracta es qué overhead tiene para cada nivel y si será posible ejecutarlo con un nivel mínimo en producción con usuarios reales.
↧
↧

Pruebas de performance desde las nubes con BlazeMeter

June 17, 2015, 12:17 pm
$
0
0
Para hacer pruebas de performance se utilizan herramientas que simulan el acceso de cientos de usuarios concurrentes sobre un sistema. Para esto, las herramientas ejecutan un script en forma concurrente, un hilo por cada usuario simulado (o Usuario Virtual como se les suele llamar). De esta forma se especifica la secuencia de invocaciones que se hacen sobre el servidor. Así podemos simular un poco más de mil usuarios virtuales desde cada PC.

Tanto con herramientas comerciales como con herramientas opensource, nos enfrentamos a una limitante al momento de querer escalar a cantidades de usuarios mayores. Si necesito simular 5 mil usuarios, uso 5 PCs, lo cual ya implica bastante trabajo de preparación, pero es manejable (incluso podrían ser máquinas virtuales en un servidor potente). Pero ¿qué pasa si necesito simular 70 mil usuarios? Este desafío lo podemos resolver utilizando algunos servicios existentes en la nube, como es el caso por ejemplo de BlazeMeter.


Esta herramienta nos permite tomar una prueba de performance hecha con JMeter (herramienta opensource muy utilizada para pruebas de performance) y definimos cuántos usuarios necesitamos simular concurrentemente (hay otras formas de definir la prueba, pero nos centraremos en esta).

El servicio se encarga de configurar (en su infraestructura en el cloud) cuántas máquinas se necesitan para ejercer esa carga (calculando como mencionamos antes unos 1000 usuarios por PC virtual) y así arranca la ejecución.

En una pantalla muy simple como la que mostramos a continuación, podemos configurar cómo queremos modelar nuestra prueba. En la imagen se ven los valores por defecto de la versión gratuita, que permite cargar 50 usuarios concurrentes, iterando por 20 minutos. Se especifica un rampup de 300 segundos (es el tiempo en el que los usuarios irán accediendo gradualmente, hasta llegar a la cantidad especificada).




Otras cosas que se pueden configurar fácilmente y que son de gran valor, es la simulación del ancho de banda de la red. Podemos por ejemplo simular que los usuarios se conectan por 3G, o por Wifi, o por ADSL, etc., o que tienen una latencia de cierta cantidad de milisegundos.

Como en una prueba de performance también es fundamental controlar el uso de recursos, también se puede integrar con herramientas como New Relic, que también tiene un enfoque SaaS en el Cloud.

Luego, la consola de administración web nos permite visualizar fácilmente como va nuestra prueba y gestionarla desde ahí. Podemos ver así el throughput (hits por segundo) y los tiempos de respuesta en función al tiempo de prueba o en función a los usuarios concurrentes.


Además de ser una herramienta que nos soluciona fácilmente el tema de cómo escalar y simular grandes cantidades de usuarios sin necesitar contar con la infraestructura de pruebas para esto, me resultó una herramienta muy buena para enseñar pruebas de performance y visualizar fácilmente cómo se realizan y qué resultados se pueden obtener con ellas, al punto que hasta la hemos utilizado en Nahual como quedó evidencia acá.

↧

Primer meetup de TestingUY, ¡un éxito!

June 19, 2015, 11:52 am
$
0
0
Ayer se llevó a cabo el primer meetup del TestingUY. Tal como describimos en la invitación en la página de meetup:

Hemos organizado ya dos eventos de forma anual (en abril de 2014 y abril de 2015), y queremos comenzar a hacerlo en forma más periódica, reuniéndonos cada uno o dos meses, generando temas de discusión, viendo las necesidades y las ganas de las personas de la comunidad de testers, y así tener más y mejores propuestas para el evento anual. 

Comenzaremos con un espacio de discusión, donde nos dividiremos en dos grupos, los interesados en hablar de pruebas automáticas, y los interesados en hablar de pruebas de rendimiento o performance. 

Seguiremos una estrategia de openspace, definiendo las temáticas a charlar entre los presentes. Esto permite que se generen discusiones e intercambios, viendo así cómo trabajan otras personas/equipos, planteando buenas y malas prácticas, buscando entre todos llegar a mejorar nuestros conocimientos.

Es por todo esto que los invitamos y los esperamos en este Meetup de testers. 


Considero que fue todo un éxito ya que concurrieron alrededor de 30 personas (mal yo que no las conté) y se dieron conversaciones muy muy interesantes.

Nos dividimos en dos grupos, en uno hablamos de performance, donde el moderador fue Andrei (el de la derecha de esta foto):



en el otro grupo hablamos de testing automatizado, donde yo me encargué de moderar (y ahí aparezco yo con parte del grupo que estuvo presente ayer.


Seguimos una dinámica de openspace, y las ideas quedaron plasmadas en estas fotos de las pizarras:




Al final de post les dejo también las notas que resumen lo charlado.

Por suerte muchos expresaron el deseo de repetir esta experiencia, ya que todos notamos que hay mucho para hablar y compartir. ¡¡Ya estamos pensando en hacer el siguiente en agosto!!


Sesión de Performance

  • ¿Qué son las pruebas de performance? ¿Cuándo hacerlas? ¿Cómo hacerlas (metodologías, recomendaciones, etc.)? 
    • El testing de performance es algo dinámico.
    • Se busca:
      • Ver cómo se comporta el sistema en aspectos no funcionales.
      • Reducir tiempos de respuesta.
      • Asegurar estabilidad. QUE NO SE CAIGA EL SISTEMA (en general es de lo más importante, lo que más le interesa al cliente).
      • Corregir errores en concurrencia.
    • Hay distintos tipos de pruebas de performance, incluso pruebas de performance para aplicaciones de 1 solo usuario!
    • Además de las pruebas, al cliente le interesa que le diagnostiquemos lo que está sucediendo. Acotar lo mejor posible el problema.
    • Es importante aclarar las condiciones en que se hace la prueba, es muy dificil representar la realidad 100%. Validar el escenario con el cliente!
    • A tener en cuenta para definir el escenario: no siempre pasa que los problemas se dan en el momento en que el sistema tiene mayor carga, por ejemplo, se pueden tener problemas de concurrencia con funcionalidades que capaz no se están ejecutando cuando sucede el pico de carga.
    • Los flujos se eligen de acuerdo a los siguientes criterios:
      • Más utilizados
      • Procesos críticos (que tengan que funcionar bien si o si, por ejemplo la funcionalidad que usa el jefe :P)
      • Funcionalidades que se sabe que son pesadas o pueden llegar a dar problemas
    • ¿Cómo se evalúan los resultados? Lo ideal sería que antes de comenzar con las pruebas se definan junto al cliente los requerimientos (tal funcionalidad debería demorar tanto, etc., etc.). Otra opción, en el caso de que sea un cambio de versión o algo de eso, es comparar los tiempos con lo que se tenía antes.
    • Etapas de las pruebas: Planificación, automatización, ejecución, análisis de resultados.
    • A veces hay que ponerse a ver el costo-beneficio de hacer pruebas de performance. Capaz te sale más barato que se te caiga el sistema a tener que pagar por pruebas de performance.
  • 2. Monitorización. Herramientas según la plataforma. 
    • ¿Qué indicadores medir?
      • Indicadores: CPU, Memoria, Access logs, gc, disco, etc.
      • Herramientas
      • Kibana, logStash, elasticsearch
      • Grafana
      • JConsole, JVisualVM
      • Nmon analyzer
      • Access logs viewers, gc viewers, etc.
    • El tester no puede saber todo, a veces está bueno que en la monitorización de una mano la gente de arquitectura, sysadmin, etc.
    • Todo el mundo interpreta las gráficas de forma diferente. Por eso es importante cuando hacemos reportes explicar nuestro punto de vista, y aclarar bien qué es lo que vemos. Si ponemos una gráfica sin ninguna expicación se puede entender cualquier cosa.
  • 3. Testing de performance en dispositivos móviles
    • Hay que separar la prueba de performance en dos partes:
      • La prueba de los servidores, que es en esencia lo mismo que las pruebas clásicas
      • Probar la performance del dispositivo en si: medir tiempos, recursos, etc. del móvil cuando se le ejecuta la aplicación.
    • En la prueba en el móvil:
      • Es como si fuese una prueba funcional, pero aplicada a performance.
      • Hay herramientas para esto? 

Sesión de automatización 

  • Comenzamos hablando de la cobertura y lo que distintas personas consideraban al momento de medir el alcance y profundidad de las pruebas. Muchos coincidieron en que es necesario un enfoque de negocio y de criticidad, y no tanto en base a líneas de código. 
  • Hablamos de cuándo comenzar a automatizar. La necesidad de que la aplicación esté con cierto estado de madurez o estabilidad, y se compartieron algunas experiencias de “pérdidas de tiempo” por comenzar muy temprano. 
  • Como todos estábamos hablando de automatización y entendiendo que se hablaba de automatización a nivel de UI, planteé hablar del patrón de la pirámide de Cohn, y a su vez del antipatrón del cono de helado. Les dejo de paso esta lectura que lo resume muy bien y en español: http://www.javiergarzas.com/2015/01/automatizacion-pruebas.html
  • En base a esto se conversó de lo importante que es tener una vista un poco cruzada con esto también, o sea, no solo automatizar a nivel de interfaz gráfica, sino que validar datos a nivel de la base de datos, utilizar servicios para preparar o para validar cosas, y si no contamos con esos servicios necesitamos colaborar con el equipo de desarrollo para contar con una aplicación más fácil de tester. Esto trae beneficios a todos, ya que ellos también estarán interesados en que la aplicación funcione bien y el cliente esté contento. 
  • También se conversó sobre la falsa seguridad que puede dar la automatización. ¿Qué tanto nos podemos confiar en el rojo o en el verde? Los falsos positivos son malos, y los falsos negativos peor. 
  • Hablamos un poco de herramientas, webdriver, Selenium y otras, y qué tanto vale la pena usar un framework hecho a construir uno nosotros mismos. La conclusión fue que se pueden tomar ideas de muchos lados y que cada uno va construyendo lo que más resultados les da. 
  • Dejo links a Seleno que nombramos ayer. 
  • Si bien este track era de automation, alguien preguntó también por la infraestructura necesaria para probar usuarios simultáneos, y en ese caso se necesitaban más de un millón. Para eso comenté de una herramienta que nos viene dando buenos resultados que es BlazeMeter, de la que escribí en el blog hace pocos días. 


↧

El problema de monitorizar la performance de sistemas virtualizados

July 1, 2015, 12:56 pm
$
0
0
La virtualización es una solución que simplifica muchas cosas, y específicamente a los testers nos han ayudado a resolver muchos problemas. Claro está, cuando hablamos de pruebas de performance, o de monitorización de sistemas en producción, el estar en un ambiente virtualizado nos agrega una capa más en el medio la cual no la tenemos que dejar de lado, sino que tenemos que estar bien consientes de cómo nos puede afectar, y cómo mantenerla bajo control.

Es muy importante que al monitorizar máquinas virtuales, nunca se haga con los contadores de performance típicos de Windows. Al menos para lo que es memoria y CPU, Windows reporta valores muy diferentes a lo que en realidad pasa.

En un proyecto que estamos trabajando para USA y UK nos pasaba que el sistema estaba limitado en capacidad de procesamiento, pero Windows nos decía que estaba alrededor de 30% de uso en cada core.

¿Cómo nos dimos cuenta qué estaba pasando?

  • Primero lo vimos con el Jet Brians Dot Trace. La nueva versión da la opción de hacer profiling con un modo timeline que muestra el CPU (¡esta muy bueno!).

  • Segundo, con los indicadores de performance que te da el propio VMWare a través del mismo sistema de monitorización de Windows (perfmon) de la máquina virtual. Si se fijan en el perf mon se agregan dos objetos nuevos "VM Processor" y "VM Memory". Estos son los que muestran la información real.

Observando la siguiente imagen del perfmon de Windows podemos ver lo que comentamos:




Las líneas de colores son del % de uso del procesador a nivel de sistema operativo, el % de CPU de siempre. Esto no muestra nada alarmante, solo que se estaba usando alrededor del 30% y en algunos momentos un poco más.
Pero si prestamos atención a la línea negra que corresponde al CPU de la máquina física (no la virtual) podemos ver que el CPU estaba saturado. Si se fijan, ese indicador está dentro del objeto llamado "VM Processor".

O sea, desde el Windows de la máquina virtual se puede monitorear la máquina física sobre la que está instalada la VM.

Esto aplica al menos para CPU y Memoria. Para los demás indicadores (al menos con VMware) no hay información específica, no queda otra que confiar en los nativos del sistema operativo, o verificarlo con otras herramientas a otro nivel de la infraestructura.

Gracias @mellimatias por la info.
↧
Search

Dump de memoria en Java ante situaciones de OutOfMemoryError

August 10, 2015, 3:59 pm
$
0
0
Muchas veces es necesario analizar un dump de memoria de un proceso Java, para ver si tenemos memory leaks, o analizar algunos comportamientos.

En Java (incluso en las aplicaciones web, configurando apropiadamente el Tomcat) podemos indicar que queremos que se vuelque automáticamente un dump cuando se dispara un OutOfMemoryError. Esto es ideal para que en esas situaciones, a posteriori, podamos analizar por qué se nos quedó sin memoria la aplicación, pudiendo así tomar alguna acción correctiva para evitar que vuelva a suceder.



Para configurar esto es necesario pasar este argumento:

  • XX:+HeapDumpOnOutOfMemoryError
Puede ir acompañado de este otro:
  • XX:HeapDumpPath
para indicar dónde queremos que nos deje el archivo. Se genera así un archivo con un nombre similar al siguiente:
  • heapdump-1428594923624.hprof
El número corresponde a un epoch timestamp con precisión en milisegundos, que cuenta el tiempo desde el 1ero de Enero de 1970. Hay varias tools online para convertirlo a date, como por ejemplo http://www.epochconverter.com/.

Luego, cómo procesar archivos hprof es un capítulo aparte, pero me resultaba interesante hacer un par de apreciaciones:
  • Con la configuración indicada arriba, estos archivos se generan sólo cuando ocurre una excepción al quedarse sin memoria. Si nosotros reiniciamos el Tomcat manualmente, no se generará. 
  • En este caso, si queremos obtener un dump de memoria antes que se genere la excepción, podemos utilizar distintas herramientas, e incluso algunas incluidas en la JDK, como por ejemplo jVisualVM o jConsole, en el tab "Monitor" hay un botón "HeapDump" que lo genera en la carpeta del Tomcat.
Por más que Java nos da soluciones con respecto al manejo de memoria y nos desentendemos de un montón de cosas, muchas veces tenemos que recurrir a este tipo de análisis para optimizar los sistemas o para evitar caídas. 

Gracias Andrei y Nico por la info!
↧
↧

Introducción a Taurus: una alternativa a JMeter

August 22, 2015, 4:56 am
$
0
0
Para los que conocen JMeter (la herramienta opensource más popular para realizar pruebas de performance), seguramente lo primero que pensaron no es “¡qué amigable es este software! ¡está clarísimo lo que hace este script!” je …

Sin dudas que uno con el tiempo va ganando experiencia y va logrando que el script JMeter sea lo más entendible posible. Nuestra herramienta (en desarrollo aún, pero funcional, gratis y open en Github) ScriptGenerator ayuda en esta tarea de generar un script JMeter de forma más sencilla y siguiendo las buenas prácticas que hemos definido.

En este post les queremos hablar de Taurus como otro approach para facilitar la tarea de desarrollar un script, así como para aprovechar otro montón de funcionalidades que nos ofrece. Taurus es una herramienta opensource desarrollada por los creadores de BlazeMeter (en adelante BM, ver nuestro post sobre esta herramienta).

La idea de Taurus es brindar un lenguaje de creación/configuración de scripts de una manera más amigable. Taurus en base a su lenguaje escrito en JSON o YAML genera scripts en JMeter, Grinder o Gatling. No solo es posible crear scripts desde Taurus, sino también utilizar Taurus con scripts pre-existentes y aprovechar sus otras bondades.

Algunas ventajas de Taurus:
  • La definición del escenario es más clara. En JMeter no es lo suficientemente clara y los plugins Ultimate Thread Group y Stepping Thread Group intentan solucionar ese problema.
  • El versionado de scripts es más sencillo. Al ser un YAML o JSON en vez de un XML.
  • La configuración del script en Taurus puede ser entendido por alguien que no tenga tanta experiencia.
  • Reportes en tiempo real durante la ejecución de la prueba.
  • La posibilidad de utilizar scripts pre-existentes
  • Integración con BM

Sobre la Integración con BM, Taurus nos permite volcar la información de la ejecución de la prueba a servidores en la nube y obtener las gráficas de tiempos de respuesta utilizando la interfaz de BM. Para el que ya conoce BM, se preguntará si es posible utilizar Taurus ejecutando en la infraestructura de BM, bueno la respuesta es no aún.

Un ejemplo de YAML de Taurus se muestra en la siguiente figura.

(fuente: https://blazemeter.com/blog/)

Este archivo define una simple prueba de carga con 10 usuarios concurrentes, un ramp-up de 1 minuto, con una duración 2m 30s e invocando a la web http://example.com utilizando GET. Esto generará un archivo JMeter con el código correspondiente para poder ejecutar la prueba definida.
Claramente es mucho más simple y legible que la prueba equivalente en JMeter.

Se preguntarán, ¿cómo hacer si debo enviar un parámetro? ¿Y si el body de un POST es un muy grande y no lo quiero en mi archivo de configuración? Aquí debajo mostramos un ejemplo completo de la definición de un request, donde el único atributo requerido es la URL. En la misma se muestra el uso de parámetros en un request, e incluso el uso de archivos para el armado de un request. El uso de variables también es permitido con el formato ${variable}. En la documentación de Taurus se puede encontrar esta información y más.

---
scenarios:
  my-req: 
    requests:
      - url: http://blazedemo.com/  # url to hit
        method: GET  # request method (GET, POST, PUT, DELETE)
        label: homepage  # sampler label

        body: 'request-body-string'# if present, will be used as body 
        body: # generate query string based on parameters and request type
          param1: value1
          param2: value2
        body-file: path/to/file.txt  # this file contents will be used as post body

        headers: # local headers that override global
          Authentication: Token 1234567890
          Referer: http://taurus.blazemeter/docs
        think-time: 1s  # local think-time, overrides global
        timeout: 1s  # local timeout, overrides global

        extract-regexp: {}
        extract-jsonpath: {}
        assert: []

¿Qué opinan de esta herramienta? ¿Les parece útil? ¿Alguien la ha utilizado en algún proyecto? Esperamos sus comentarios.
↧

7 tips para conocer y documentar los requisitos cuando no contamos con ellos para testing

September 18, 2015, 7:19 am
$
0
0
Creo que todos los que hacemos testing nos hemos enfrentado a tener que probar algo sin tener los requisitos documentados, ¿cierto? Si no es así, ¡qué afortunado que sos!



Para el resto de los mortales que nos hemos enfrentado a estas situaciones, les dejamos acá unos tips que nos dejó Pilar Albacete, una de las líderes de testing del equipo de Abstracta. Estos son algunos tips para armar una Especificación de Requerimientos (EsRe) que recogió en su experiencia en un proyecto, en el cual al no contar con requerimientos definidos, se comenzó haciendo un trabajo fuerte de documentación de los mismos, con el objetivo de luego tener un punto de referencia para poder probar el sistema. Esta documentación además servirá luego al cliente para otros fines, desde definir procesos, metodologías, manuales de usuario, o incluso si algún día deciden cambiar el sistema, tienen bien claras cuáles son sus necesidades.



Tip de EsRe 1: Kick Off de Inicio de Proyecto: 
Realizar un Kick Off con usuarios e interesados permite lograr un mayor compromiso en el proyecto, ya que se presenta los objetivos del proyecto, la forma de trabajo definida, la participación que se va a requerir de cada uno, y la responsabilidad de cada uno.

Tip de EsRe 2: Contar con un Modelo de EsRe del Cliente:
Si el Cliente cuenta con documentación de especificación ya realizada, se recomienda solicitarle revise el formato y redacción y realice las modificaciones que considere necesarias, para luego poder tomar este ejemplo como base en cuanto a forma de redacción, tiempo de verbos, formatos, tipos de letras, colores. En el caso que no cuenten con uno, se deberá proponer una alternativa y validarla con el equipo.

Tip de EsRe 3: Entrevistar a Interesados y a Usuarios.
Buscar que se ahonde lo más posible en lo que detallan y necesitan, ya que los usuarios tienen todo en la cabeza y pueden asumir que uno entiende todo lo que están hablando,
Buscar llevarlos con preguntas, repreguntas y conclusiones, que piensen secuencia de pasos para poder ordenar sus necesidades. Luego, validar lo documentado con cada participante como se comenta en el último tip de este post.

Tip de EsRe 4: Definir una Sección de Reglas de Negocio:
Cada requerimiento debería contener una sección de Reglas de Negocio, ya que es muy importante que se especifiquen supuestos y restricciones surgidas del relevamiento. Estas reglas inciden en la determinación de casos de uso de ese requerimiento y de otros requerimientos que puedan estar relacionados.

Tip de EsRe 5: Especificar los Datos de cada Requerimiento:
Conviene dejar bien claro para qué se usa cada elemento de las pantallas (etiqueta, lista desplegable, combos, cajas de texto) que forman parte del caso de uso.
Se recomienda documentar estas definiciones en el Cuadro de Especificaciones de Datos del Requerimiento. En este cuadro no se tiene que apuntar a tipo de datos, ni a validaciones, sino a definiciones. Por ejemplo, especificar en los campos fechas desde y hasta para la creación de una instancia de una determinada entidad qué significan y de dónde surgen y para qué se ingresan. Otro ejemplo, si tenemos un campo para el interés por financiación, se debería detallar qué es, para qué sirve, qué fórmula se aplica, qué período se considera en el cálculo y dónde se especifica este periodo. No alcanza con indicar el tipo de datos y la validación que se podría hacer en pantalla, ya que de esta forma evitaremos ambigüedades o confusiones.

Tip de EsRe 6: Incluir un Cuadro de PreCondiciones y PostCondiciones
Estos cuadros dan una visión más global de los flujos o pasos de los procesos más a alto nivel. Tiene como objetivo visualizar a nivel de requerimiento con que otro/s requerimiento/s se tiene que continuar para poder avanzar en el proceso definido.

Tip de EsRe 7: Planificación y Validación de EsRe.
Incluir en la planificación de relevamiento la validación de los mismos y acordar con el cliente el tiempo que le van a dedicar a dichas validaciones.


Esperamos que les sean útiles y se animen a compartir algunos otros basados en su experiencia.

↧

Preparándonos para el Encuentro GeneXus 25, What's next?

September 22, 2015, 8:48 am
$
0
0
Como todos los años, los días antes del Encuentro GeneXus, estamos todos con los últimos ajustes para las charlas, revisando el programa y definiendo a qué charlas quisiéramos ir.




Les resumimos en este post la participación que tendrá el equipo de Abstracta en este encuentro:



Si revisan el track de testing verán que hay varias charlas más que están interesantes al respecto, así que hay mucho material para aprender.

Además, estaré junto a Alejandro Lazar contando sobre el Proyecto Solidario Nahual, a través del cual estamos trabajando en capacitar y brindarle oportunidades laborales a jóvenes que no les es posible cursar en la Universidad, mejorando así sus posibilidades de llegar a obtener un trabajo en el campo de IT, que todos sabemos que tiene desempleo cero y que les puede cambiar la calidad de vida en comparación a las ofertas laborales a las que pueden llegar hoy en día. La herramienta que les brindamos es el testing, como una forma de acceder rápidamente a este campo laboral. Vamos a compartir los logros de todo este primer año de trabajo, donde ya hay más de 20 egresados, 3 chicos están trabajando y 25 se están capacitando en este momento.


Luego del evento, el 1ro de octubre, también en el Radisson, estaré dando un curso de 4hs junto a Giulliana Scuoteguazza llamado "Verificando la calidad y el rendimiento de las aplicaciones desarrolladas con GeneXus".


Esperamos contar con la presencia y apoyo de los amigos de siempre, con lo cual esperamos verte ahí. Tengo muchas expectativas de este evento al igual que todos los años, y me encanta formar parte del mismo.

¡Nos vemos!



Participaciones en años anteriores:
↧

Monkop en TechCrunch Disrupt SF 2015

September 23, 2015, 8:31 am
$
0
0
Este evento que se está celebrando en estos días en San Francisco, es el lugar en el que las startups quieren estar para llamar la atención, para darse a conocer. Es así que Monkop y AbstractaUS están en el pabellón de Uruguay en este evento.


Les queremos pedir un voto para conseguir 6 minutos para presentar Monkop a todo el público presente. Para eso simplemente tienen que entrar acá y votarnos.

http://startupalleysf15.techcrunch.com/index.php?comp=241

Es una competicion que le llaman Startup Battlefield competition. El premio más importante es estar presentando a todo el público ahí presente. ¡Por esto es que significa de mucha ayuda el apoyo de cada voto!

Este video explica más sobre el evento y la votación.



¡Tenemos al Monkop tamaño persona dando vueltas por ahí! Tal como el año pasado estuvo en el Encuentro GeneXus en Montevideo, ahora anda paseando y sacándose fotos por San Francisco.


↧
↧

Las 3 cosas que me gustaron más del encuentro GX25

October 8, 2015, 10:34 am
$
0
0
Ya pasaron unos días del Encuentro GeneXus número 25, y como siempre, un placer haber sido partícipe. Muchos abstracteros estuvimos a la vuelta del evento, divirtiéndonos y disfrutando de las diversas propuestas de charlas.


Resumo aquí las cosas que me gustaron más de esta edición:

#1 - La gran participación de Abstracta en el evento

Este año participamos en 5 charlas en los 3 días del evento, y en un seminario al día siguiente:

Las 5 charlas tuvieron muy buena concurrencia, incluso considerando que en algunos casos competían con otras muy buenas. Esto nos indica claramente que hay un interés muy fuerte por una comunidad de testers que existe dentro de la comunidad GeneXus.




El jueves 1ro de octubre, junto a Giulliana Scuoteguazza, brindamos un tutorial "Verificando la calidad y el rendimiento de las aplicaciones desarrolladas con GeneXus", donde certificamos a unas 15 personas de diversos países.



En lo personal también participé de otra charla, junto a Alejandro Lazar, donde hablamos del Proyecto Solidario Nahual: Testing: ¿una alternativa laboral para nuestros jóvenes?

#2 - La cantidad de cosas que aprendí

La verdad que los contenidos de las charlas fueron muy variados, y considero que todos aportaron mucho. En particular me interesó mucho la temática de Internet de las cosas, mostrando muchos ejemplos en los que se está aplicando e investigando. También está muy bueno ver que algunos colegas y amigos ya están trabajando en estas tecnologías, y cómo GeneXus permite estar como siempre en la cresta de la ola.

#3 - Contacto con la comunidad

Como todos los años, una de las cosas más importantes es contactar a la gente de la comunidad, teniendo la oportunidad de ponernos al día y ver en qué está trabajando cada uno. Se da mucha chance a colaborar y generar nuevas sinergias.
En particular tuvimos la oportunidad de conocer clientes del exterior, que hasta ahora sólo los conocía por Skype. Esto es algo por lo que siempre uno termina valorando muchísimo al evento, ya que, a diferencia de otros países, tenemos una gran oportunidad gracias a que todo se da en Montevideo.

Concluyendo

Cuántas cosas tenemos para seguir explorando y trabajando, y cómo estos encuentros nos ayudan a mantenernos contactados y en camino.
¡Felicitaciones y mil gracias a todos los que lo hacen posible! y también ¡felicitaciones y gracias a todo el equipo de Abstracta por la gran participación!
↧

La Carrera Profesional del Tester: una Infografía

October 19, 2015, 10:56 am
$
0
0
Una pregunta que toda persona se hace cuando comienza a trabajar en cierta área, es sobre el posible futuro que podrá tener ahí. No es lo mismo comenzar en un lugar que sabemos que no tenemos chances de crecer, a meternos en un área donde con el tiempo podremos ir aprendiendo y de esa forma escalando. 

Esto es lo que sucede en el área de testing, con el tiempo y con la práctica nos iremos haciendo mejores testers, y por este motivo, podremos aspirar a mejores posiciones, a aumentos salariales, a más responsabilidades, a tareas más desafiantes, más entretenidas, a seguir aprendiendo, y estar siempre en un ciclo virtuoso de mejora (mejora de nuestras capacidades y así mejora de nuestro trabajo).

La “carrera de tester” tiene distintos caminos. O sea, uno puede profesionalizarse y crecer por distintas ramas, las cuales deberíamos tener claras con anterioridad, para poder visualizar hacia qué lado te gustaría crecer, ya que para cada rama se necesita trabajar en mejorar distintos aspectos, y se llega a tener distintas tareas a cargo.

En la siguiente infografía puedes ver un esquema que representa algunas de las posibilidades que tienes transitando por la carrera profesional de testing. 


Si quieres ver algo más completo aún, aunque en inglés, en este enlace hay un mind map donde hicieron un análisis muy bueno sobre el futuro del software testing, y en particular enfocaron cierta parte del análisis a las posibles carreras que puede seguir un tester.

A continuación veremos un posible camino a transitar. Depende de cada uno el cómo se de esto, pero algo que tiene el testing que no lo tienen otras áreas de la informática, es que se puede comenzar a trabajar con poca formación técnica en programación y similares (es por esto que tienen sentido iniciativas sociales como Nahual).

Parte del análisis hecho abajo lo armé en base a la encuesta de salarios dentro del mundo del testing, que ofrece la gente de expoQA de España.

El inicio

Al arrancar sin experiencia en testing, uno aspira a un puesto de tester junior. En algunos lugares se acostumbra a pasar primero por un período de “trainee” o “practicante”.
Típicamente se considera Tester Junior al que tiene menos de 2 años de experiencia total. Las tareas que se les asignan son variadas según el equipo, pero para tener una idea podrían ser más que nada estas:
  • Ejecutar tests
  • Reportar defectos
  • Diseñar casos de pruebas simples
  • En ocasiones está involucrado en otras actividades de mejora de la calidad.

Ganando experiencia

Luego de estar un tiempo ejecutando pruebas, uno va aprendiendo en el camino de varias formas, especialmente por la práctica… uno va viendo dónde fallan típicamente las aplicaciones, vamos entendiendo mejor el proceso de construcción de software, vamos adquiriendo práctica con distintas tecnologías y herramientas, vamos mejorando nuestras habilidades de comunicación, y así pasamos al siguiente nivel, el cual se lo conoce como tester semi-senior, o tester medio. Este puesto suele ser de los 2 a 4 años de experiencia total, 1 a 3 años de experiencia en testing. Las responsabilidades podrían ser:
  • Ejecutar tests
  • Reportar defectos
  • Diseña casos de pruebas complejos
  • Estar cada vez más involucrado en otras actividades de mejora de la calidad.
Luego de esto pasaríamos a tener una posición de Tester Senior. Típicamente se considera que uno es tester senior cuando cuenta con entre 3 a 10 años de experiencia en testing.

Consultor QA

Gente con mucha experiencia en el rubro pasa a dar servicios especializados. Acá es donde entran en juego los consultores, que básicamente aportan valor con su gran conocimiento y experiencia, identificando problemas y planteando mejoras en los equipos, enseñando a usar herramientas o a adaptarse a procesos y metodologías. 

Managers o Líderes

Luego están los roles de management, o en español, de gestión. La idea es que estas personas son las que se encargan de organizar el trabajo, especialmente cuando se trata de un equipo de personas dedicadas al testing. 
De acuerdo a los años que esa persona esté gestionando equipos, tendremos a veces “test manager junior” o “test manager senior”, y de acuerdo a la experiencia estas personas serán capaces de gestionar y organizar un equipo más pequeño o uno más grande. En algunas empresas una misma persona tiene que gestionar las pruebas de muchas aplicaciones, en otras solo se dedican a una en particular. Aquí es muy importante desarrollar las habilidades de comunicación, liderazgo, organización, etc.

Tester Técnico o Automatizador

Hay testers que aprenden a programar (o programadores que aprenden a testear), con lo cual son los que se pueden encargar de las tareas más técnicas del testing. 
Encontramos así a personas que nos ayudan a automatizar todas las tareas repetibles. Se los conoce como automatizadores. También dentro de los testers técnicos encontraremos a los testers enfocados en performance y en seguridad. Para estos tipos de pruebas es necesario contar con conocimientos profundos de sistemas operativos, bases de datos, servidores, etc., pero es una rama de las tantas posibles a explorar (y que en particular a mí siempre me han apasionado). 


Esperamos así transmitir qué posibilidades de crecimiento personal y profesional tiene una persona que se mete en el mundo del testing. También te invitamos a que si te interesa transitar este camino, estés en el nivel que estés, nos escribas contándonos tus ganas de testear, tus skills y tus proyecciones en la carrera profesional de tester (curriculum@abstracta.com.uy)
↧
Search

¿Cómo lograr que una Aplicación GeneXus no se Estrese?

October 24, 2015, 5:04 pm
$
0
0
Una de las charlas que brindamos en el Encuentro #GX25 fue relacionada al testing de performance. Aquí les dejamos un apunte de las principales ideas conversadas durante el mismo.


Pueden ver la presentación, fotos y materiales aquí.

Para introducirnos en el tema, Leticia Almeida, junto con Andrei Guchin, nos hace una pregunta bien interesante: ¿cómo evitar que una aplicación desarrollada con GeneXus se estrese frente a concurrencia, o sea, frente a determinada cantidad de carga de usuarios simultáneos?

¿A quién no le ha pasado de estresarse al estar utilizando una aplicación ya que la app no carga,  o anda lenta, o queremos llenar un formulario y se borran todos los datos que ingresamos? Estas son cosas que suceden habitualmente, y nosotros cada vez somos más exigentes, y queremos que estas aplicaciones respondan de manera inmediata.

Con las pruebas y la Ingeniería de Performance estaremos logrando el objetivo de que las aplicaciones respondan en los tiempos que estamos exigiendo.

En la charla se habló sobre pruebas de performance abordando estos aspectos:
  • ¿qué son las pruebas de performance?
  • ¿cómo ayudamos con este tipo de pruebas?
  • ¿qué logramos con este tipo de pruebas?
  • la metodología que se utiliza a lo largo de un proyecto de pruebas de performance, 
  • una experiencia de un proyecto real, 
  • y finalmente las conclusiones.

¿Qué son las pruebas de performance?

Comenzando por la introducción, vamos a intentar comprender lo qué es Performance.
Nosotros medimos la performance, como el trabajo útil que hace un software en comparación con el rendimiento y en comparación con los tiempos de respuesta que tenemos.

Es decir que con las pruebas de performance se mide el rendimiento de la  aplicación y de todos los componentes con los que interactúa esta app. Ya sean servidores, base de datos, etc., todos los componentes de una determinada infraestructura se medirán con las pruebas de performance, obteniendo de esta manera, los tiempos de respuesta. 

¿Cómo ayudamos con este tipo de pruebas?

Ayudamos simulando situaciones de carga en un entorno controlado, pudiendo hacer análisis y optimizaciones previo a la puesta en producción, verificando cómo impacta cada uno de los cambios y optimizaciones que queramos intentar. 

¿Qué logramos con este tipo de pruebas?

Pensémoslo de esta forma: ¿qué riesgo corremos si salimos a producción sin las pruebas de performance?

En producción vamos a tener concurrencia, que esto no se ve con las pruebas funcionales.
Cuando los usuarios finales estén ingresando información en los formularios, la aplicación puede que no soporte la carga y se caiga. Perderemos todo lo bueno que tiene la aplicación, estaremos perdiendo confianza, credibilidad, al cliente, tendremos costos indirectos, costos de mantenimientos de esa aplicación. Tendremos un montón de problemas difíciles de solucionar.

Entonces, lo que logramos es disminuir este tipo de riesgos y este tipo de problemas. 

Metodología de pruebas de performance




Diseño de Prueba

La siguiente imagen describe los principales puntos a considerar en esta etapa:



Definir los objetivos
Debemos entender ¿para qué hacemos las pruebas de Performance? Porque de eso depende en qué vamos a poner foco.

Diseño de casos de prueba
Elegir flujos por los cuales estaremos ejecutando.
Para elegir los flujos tenemos que tener en cuenta:
  1. Flujo que utilice demasiado.
  2. Funcionalidades que interactúan con todos los componentes del  Sistema.
  3. Funcionalidades críticas.
Escenarios de Carga
Luego tenemos que definir los escenarios de carga, que lo mejor es definirlo en el peor caso.

Criterios de Aceptación
Los criterios de aceptación son condiciones o requisitos que el cliente pone.

Relevar Infraestructura
Las pruebas de performance se realizan para medir el rendimiento en cada componente, para medir la memoria, el disco, uso de CPU, cuello de botella en algún componente, si está mal configurado, etc. Todas esas cosas las estaremos definiendo al determinar la Infraestructura. 

Diseñar Datos de Prueba
Por último estaremos definiendo los datos de prueba, en dónde tenemos que tener en cuenta dos cosas, tenemos dos tipos de datos de prueba, los inputs que necesita cada script de prueba (que corresponden a los datos que ingresa un usuario en la pantalla) y por otro lado los datos de la BD (que por cierto, debe tener un volumen lo más similar posible a lo que sería producción, ya que de otra forma nos perderíamos de detectar muchos problemas).


Luego toda esta información que definimos para la realización de las pruebas deberá ser validada por los interesados en la prueba. 


Implementación de la Prueba

Como veíamos, la siguiente etapa es la de implementación. En esta etapa básicamente se prepara todo lo necesario para ejecutar las pruebas. A diferencia de las pruebas funcionales, realizar una prueba de performance "manual" es muy costosa (se necesitaría, por ejemplo, 100 personas, 100 computadoras con acceso a la aplicación, y coordinar a las personas para que realicen lo que queremos probar… y cuando hablamos de 1000 o 2000 personas se complica más aún).

Es por esto que tal vez la tarea principal que se realiza en esta etapa es la automatización, donde se preparan los elementos que simularán los flujos que realiza un usuario real.

Para esto contamos con herramientas específicas. En la imagen aparecen algunas de las existentes, en particular son las que más utilizamos. OpenSTA y JMeter son gratuitas, tal vez las más populares, y nos han dado muy buenos resultados. En el caso de BlazeMeter es una herramienta que funciona en la nube y ejecuta scripts de JMeter, dándonos flexibilidad a ejecutar gran cantidad de usuarios sin necesitar infraestructura de pruebas. 


Además,  esta etapa generalmente se aprovecha para configurar las herramientas de monitorización que se van a estar utilizando en las ejecuciones.
La monitorización es necesaria para la prueba, no es suficiente conocer los tiempos de respuesta si queremos mejorarlos, también es necesario conocer el estado de salud de los servidores cuando están trabajando (CPU, memoria, disco, red, etc.).
Como en las herramientas de automatización, acá también hay que considerar que hay gratuitas y pagas. Algunas de las que monitorizan desde la nube: AppDynamic y New Relic.

Ejecución de Pruebas

Cuando se tiene todo pronto, se pasa a la etapa de ejecución donde, obviamente, se ejecutan los casos de prueba automatizados.

Lo primero que se ejecutan son los baselines, que consisten en ejecutar cada flujo individualmente y en lo posible siendo la única funcionalidad que se esté ejecutando en el sistema en ese momento, de forma tal de obtener los mejores tiempos posibles y tener valores de referencia contra los cuales comparar el resto de las ejecuciones.

Luego, se procede a ejecutar el escenario definido (el cual lo consideramos el 100% de la carga). Se recomienda ejecutar de forma incremental, arrancando por ejemplo, con un 20% de la carga, y a medida que se van obteniendo buenos resultados se va a aumentando al 50, 75, hasta llegar al 100%.
De esta forma los problemas más graves van a saltar primero (que en general son los que queremos resolver antes).

Al ser la última etapa del proyecto, generalmente es la que está más acotada de tiempo, pero a veces las ejecuciones dan buenos resultados y se llega al 100% de la carga rápido. En esos casos, siempre se aprovecha para ejecutar con más carga de lo esperado (150% o 200%) ya que nos da información de qué tanto más puede crecer nuestra carga de usuarios y cómo el sistema se comportaría en esos casos, o incluso poder hacer alguna prueba de endurance ejecutando por 6 u  8hs de corrido.

Luego de cada ejecución se analizan los resultados que se obtuvieron. Generalmente lo primero que miramos son los tiempos de respuesta, pero solo esto no alcanza, así que también miramos recursos de los servidores. Observemos algunas gráficas de memoria y CPU.



Acá por ejemplo se puede ver un lindo memory leak… En las gráficas que muestran el uso de memoria y el comportamiento del garbagge collector, se puede ver cómo a partir de cierto momento se empieza a acumular memoria y no se libera… En la gráfica de memoria de arriba se muestra el heap de la JVM. Ahí se puede ver en cierto momento que se produce un consumo abrupto de memoria; esto da la pauta para poder revisar cuáles son los procesos que se estaban ejecutando en ese momento, y ver si está bien o no que consuman tanta memoria.
Tampoco hacemos nada mirando esto, esto son síntomas, tenemos que buscar las causas (es la tarea más difícil y la más entretenida).

Experiencia de un proyecto real

Veamos para ejemplificar un caso real, en particular el proyecto de pruebas de performance de historia clínica electrónica oncológica del programa salud.uy en el que participamos para AGESIC.

Es un sistema diseñado para mejorar la atención de pacientes oncológicos en todo el Uruguay, tanto de las instituciones privadas como públicas. Por lo tanto, tratándose de algo de este estilo, donde los “clientes” están en una situación tan sensible (además de que es algo a nivel gubernamental y todo lo que eso implica), era muy necesario asegurar el correcto funcionamiento de la aplicación, que sea rápida, que no se tranque, que ni los pacientes ni los médicos tengan que escuchar la típica frase “se cayó el sistema”.

En la etapa de diseño se definieron todas las cosas que veíamos anteriormente:
  • El escenario se definió en base a la cantidad de pacientes que son atendidos por hora en todas las instituciones (se simuló la hora pico).
  • El ambiente de pruebas, igual al de producción.
  • Los flujos a simular (casos de prueba): primera consulta, etc.
  • Los datos de prueba.
Es importante VALIDAR todas estas cosas con el cliente, sino en las otras etapas se complica estar realizando cambios o agregando cosas.

En la implementación se  automatizaron los casos de prueba elegidos y se configuraron las herramientas de monitorización.

Luego se ejecutaron las pruebas en base al escenario definido. Se dedicaron más o menos dos semanas. Si bien no es la etapa que lleva más dedicación, es la etapa que le da más valor al cliente, donde se detectan los problemas, cuellos de botella, memory leaks, etc., y se trabaja en buscar soluciones.

Los resultados de las pruebas fueron muy buenos, se verificaron que los tiempos de respuesta fueran aceptables, y que el riesgo de tener problemas de performance para la carga que se estimaba tener fuera muy bajo, y así se pudo salir más tranquilos en producción.

Conclusiones

A modo de conclusión, queríamos responder la pregunta que da título a la charla: ¿cómo lograr que una aplicación GX no se estrese?


  1. Primero que nada incluir las pruebas de performance en la cultura de la empresa. Cuesta mucho más trabajo, y dinero, estar apagando incendios en producción por cosas que se podían haber prevenido. Y esto de la cultura es  porque no basta solamente con hacer una sola prueba una vez, mejorar cosas y listo… tal vez mejoramos algo, pero al actualizar el sistema van a aparecer cosas nuevas, por eso hay que tomarlo como costumbre...
  2. Luego aplicar la metodología que acabamos de explicar (u otra, nosotros les mostramos esta porque es la que hemos adoptado y la que nos ha dado muy buenos resultados).
  3. Finalmente, con los resultados, encontrar las causas y aplicar las mejoras, optimizaciones y corregir los errores.
Siguiendo estos pasos, van a poder reducir notablemente la probabilidad de sufrir problemas en producción en lo que se refiere a performance.

↧

La Carrera Profesional del Tester: ¿hay techo?

October 25, 2015, 6:21 am
$
0
0
Luego de publicar el post en el que habla sobre la posible carrera profesional de un tester, recibí varios comentarios y dudas:

  • ¿Qué pasa si a mi me gusta diseñar y ejecutar pero no me gusta la gestión ni lo técnico?
  • ¿Esos tiempos de crecimiento son fijos?
  • ¿Qué hay después?

Como todo trabajo, uno va progresando a medida va tomando más responsabilidades, aprendiendo cosas nuevas, logrando hacer más y mejor... Yo creo que también pasa que uno va descubriendo nuevos gustos a medida avanza. 

Por ejemplo, al ver que con la sinergia de un equipo logramos hacer más y mejor, eso te va llevando a querer entender mejor cómo trabajar en equipo, a dividir tareas y organizar. Otro ejemplo podría ser que uno ve que logra hacer mucho más trabajo y ahorrarse las cosas repetitivas gracias a la automatización, entonces tal vez, sin ser incluso programadores, se animan a probar algunas herramientas y ahí descubren otro gusto por la parte técnica que no habían visualizado antes. 

Claro que después de eso hay mucho más. Podemos especializarnos en el mundo ágil, podemos variar en distintos tipos de técnicas o herramientas, podemos variar de tecnologías, podemos volvernos más y más expertos en un área de negocio, podemos también apuntar a contagiar a más y más gente, llevando nuestro perfil hacia la docencia o la difusión, ya sea por eventos y meetups, o por redes sociales, escribiendo e investigando al respecto. 

No es una carrera marcada, que haya que pasar cada meta en los tiempos mencionados, eso no es fijo. Hay que dejarse llevar, entrar en el proceso de mejora continua, de crecimiento personal, e ir descubriendo por dónde queremos seguir explorando nuestras habilidades y desarrollando nuestro potencial. No hay techo :)

Nota al pie: me baso en los logros que he visto en testers que conozco de Uruguay, Argentina, España, Italia, Brasil, USA, y gente que me he cruzado en conferencias, meetups, que leo sus artículos, etc., que me inspiran a pensar que realmente no hay techo.
↧
↧

Las cosas que más me gustaron de #Agiles2015

October 25, 2015, 12:42 pm
$
0
0
Las octavas jornadas latinoamericanas sobre agilismo se celebraron en Montevideo en la semana pasada. Fueron 3 días (22, 23 y 24 de octubre) de aprendizaje y de compartir con mucha gente de distintos países, en diversos temas relacionados al mundo ágil que tan de moda está en los últimos años, y que trasciende la informática (aunque creo que casi todos los asistentes eran informáticos). Temas que iban desde la educación, coaching, equipos de trabajo, testing, experiencias, etc.


Tuve la oportunidad de asistir y les resumo las cosas que más me gustaron, las cuales dan ideas de qué seguir investigando y profundizando, como para que cada uno pueda adoptar lo que considere que le aporta.

Pasión, objetivo de cambiar al mundo

Un colega con el que me encontré en la conferencia me dijo "acá están los hippies de la informática". Son gente rara, gente que tiene valores que en otras conferencias o grupos de personas no se ven. ¡Y cuidado que contagian!

Es inspirador ver tantos valores que son ideales: transparencia, auto-organización, excelencia técnica, foco en las personas, calidad en lo que se le entrega al cliente. Pero si bien todo esto son valores que uno comparte, es muy interesante la forma en que lo plantean y lo intentan transmitir.

Por poner un simple ejemplo, en una charla el orador logró que todo el público se ponga a bailar (sí, recuerden lo que puse antes, todos informáticos). Planteó que podemos proponer cambios, y realmente los logró.
En todas las propuestas hablaron de poner sobre todo a las personas, a disfrutar trabajando, a hacer las cosas bien. Management 3.0 y peopleware, son conceptos usados con frecuencia.

Ya el primer día quedé sorprendido positivamente del buen nivel de oradores y contenidos. La organización del evento fue genial también.

Estuvo muy bueno conocer empresas como 10pines y todos los valores que llevan adelante de una forma muy leal, y confían tanto en la forma en la que trabajan y enfocan su empresa, que quieren contagiar a más gente porque creen que es una forma de cambiar el mundo hacia algo mejor.

Variedad de propuestas y dinámicas

Todo lo que se hace se hace con alguna práctica ágil (hay quien propuso que hasta la comida y bebida se podría organizar en forma ágil). 

El openspace es la muestra máxima quizá, donde todos proponen temas y se van organizando automáticamente para que entre todos se arme la agenda del día. Esta fue la propuesta para el 3er día. Los dos primeros días fueron charlas organizadas por un comité, y el tercer día fue completamente libre, y lo interesante es que no quedó ningún tema afuera. Incluso para lograr que todos tengan su lugar, se generaron nuevos espacios (se dividieron salones, se propuso hasta reunirse en la calle o pasillos).

OpenSpace, la gente proponiendo temas:



Y finalmente se llegó a la agenda de "charlas" o "meetings":



El evento terminó con una gran retro (retrospective meeting). Eso es otra muestra de aplicar agile en la conferencia misma. En la foto se puede ver toda la gente que participó de esa retro:



Había un happiness wall, para obtener feedback e ir corrigiendo cosas durante el evento. Todos tenían la posibilidad de destacar cosas buenas y malas, y así los organizadores tenían chance de ir corrigiendo. 




Participé en algunos talleres. Uno en particular con Legos, donde los mentores guiaban los ejercicios a hacer para sacar un montón de conclusiones bien interesantes. Hay toda una movida alrededor de los cuadraditos de colores :)




En otro taller usamos una herramienta para aprender Kanban que era un juego (lamentablemente la versión online no es gratuita, pero aquí uno puede bajar el tablero e imprimirlo) en el que uno "ganaba dinero", y que para ganar uno tenía que seguir las buenas prácticas que esa estrategia propone. Muy ilustrativo realmente. 

Realmente muy revelador todo. 

Facilitación gráfica

Esto fue algo completamente nuevo para mí, y veo que está muy inmerso en el mundo ágil. Hace tiempo que venía escuchando de este tipo de cosas y algo había estado estudiando, pero me animé a hacer un workshop con Claudia Sandoval (¡una verdadera artista!) el cual estuvo muy entretenido e ilustrativo, intentando perder el miedo de dibujar y así presentar ideas, resumirlas, compartirlas. 

Durante el evento cada charla tenía su facilitación gráfica en manos de gente con mucha experiencia en el tema, con lo cual había un resumen de todas ellas. Acá algunas:




En esta aparece Claudia:


Nahual

El proyecto solidario Nahual en Uruguay nació en el Ágiles2013, cuando un uruguayo participó del open space, donde Pablitux participó contando de esta loca idea que llevan adelante en Argentina hace ya tantos años, buscando combinar inclusión social y tecnología.

Así plantó la semilla que se nos fue contagiando a varios de a poco, y hoy es un proyecto con resultados reales también de este lado del Río de la Plata. 
Una de las mejores cosas de estos 3 días fue tener la posibilidad de conocer personalmente a las figuras argentinas que están hace tantos años con esta iniciativa. 
También conocimos a algunos que están iniciando esto en Colombia y Bolivia.
Estuvo genial conocerlos y generar más confianza y vínculo, buscando mayores sinergias a futuro.



Espacios de discusión 

Realmente sentí espacio para plantear dudas y compartir ideas con la gente. El openspace tiene una magia especial para estas cosas. Las charlas nos dan la posibilidad de escuchar a alguien que quiere compartir algo, pero generalmente si el tema es interesante no da el tiempo para poder consultar y discutir en el espacio a preguntas. Además, hay una estructura bastante rígida impuesta por los roles de "presentador" y "audiencia". En los openspace se plantea algo más horizontal. Alguien propone un tema, tal vez hasta introduce algún concepto o dinámica, pero hay mucho más espacio a esa discusión que es lo que enriquece plenamente. 

No digo que todo haya que hacerlo en ese formato, ya que las charlas logran cosas que no se logran tan fácil en un openspace, como el poder abordar un tema en forma más integral y ordenada, pero creo que es un muy buen complemento. 

Cerrando...

Haré lo posible por no perderme este evento en los años venideros ya que me resultó súper provechoso. ¡Felicitaciones a todos los que lo hicieron posible!


Nota: casi todas las fotos fueron tomadas del Twitter de @agiles2015
↧

¿Cómo evitar problemas de performance al pasar a producción, luego de haber hecho pruebas de performance?

November 6, 2015, 7:35 am
$
0
0
La regla de Pareto del 80-20 se aplica claramente a la monitorización de sistemas. Generalmente el 80% de la información valiosa la obtenemos del 20% de los indicadores. 

Muchas veces un parámetro insignificante nos puede alterar el comportamiento de todo el sistema. Si queremos ver esto en forma más positiva podríamos decir que un pequeño ajuste a veces nos mejora notoriamente la performance del sistema. 

¿Qué pasa si hacemos pruebas de performance y optimizamos el sistema, pero al pasarlo a producción no configuramos la aplicación tal como la teníamos en el ambiente de pruebas? Un pequeño parámetro nos puede cambiar la performance del sistema, y obviamente que lo primero que se va a pensar es ¿por qué si las pruebas daban buenos resultados, al salir en producción tuvimos esta mala performance?

Esto es lo que marca la importancia de mantener un buen registro de todos los parámetros que se configuraron, todas las optimizaciones hechas durante el proceso de pruebas de performance, y asegurarse que al momento de poner el sistema en producción se repliquen todos los parámetros y configuraciones del ambiente donde hicimos el test. Debemos ser metódicos y cuidados con esto. Aquí se nota la importancia del rol de un devops para esto, alguien que esté involucrado desde el proceso de desarrollo, que esté metido en las pruebas de performance y luego también en la puesta en producción. Esto evitaría problemas de coordinación o comunicación que puedan existir entre distintos equipos. 

Y para cerrar este breve post con algo que nos deje pensando su analogía con la monitorización de sistemas, como dice Petyr Baelish en Game of Thrones, "What we don't know is what usually gets us killed".


¡Gracias Andrei por la quote!
↧

Pregunta de examen en Nahual: ¿Por qué es importante el testing en un proyecto de desarrollo de software?

November 17, 2015, 1:29 pm
$
0
0
El sábado pasado quedé positivamente asombrado, muy feliz por el resultado obtenido en el examen de Nahual (si aún no conoces este emprendimiento social en el cual todos los informáticos encontramos un lugar ideal para contribuir e intentar aportar un granito de arena a la sociedad, puedes enterarte acá, o en su página web nahual.uy).



El examen consistió en un formulario con pocas preguntas, y la idea era que no usen material ni ningún apunte, sino que los chicos expresen con sus palabras lo que ellos entendieron y se acuerdan sobre los conceptos sobre los que les preguntamos (participaron 15 de los 25 chicos que hicieron el curso este cuatrimestre en Nahual).

La primera pregunta planteaba lo siguiente: ¿Por qué es importante el testing en un proyecto de software? Les copio las respuestas abajo**, no tienen desperdicio, en especial porque lo que estos chicos (de entre 16 y 22 años, sin bases tecnológicas, sin carrera en informática) muestran haber comprendido en muy pocas clases de testing en las que consiste el curso, algo que hoy día muchas empresas aún no tienen claro. Desde el equipo de Nahual esperamos hacer un empuje a mejorar el conocimiento, la necesidad y la solución que da el testing a la industria del software:

**Aclaración: copié y pegué las respuestas, sin editarlas.

  • Por què podremos  averiguar en que tiene que mejorar un programa y cuales pueden ser sus principales fallas y aspectos ah mejorar, junto a sus puntos fuertes  y lo que falta para llegar a lo que se nos pide .
  • El testing es importante porque sirve para planificar, modificar y probar en base a las especificaciones de un determinado programa que se utilizará por usuarios en un futuro. Esto es imprescindible para que dicho programa tenga un buen funcionamiento y así el/los usuarios puedan utilizarlo sin ningún problema.
  • El testing es importante porque ayuda a mejor un programa y por ejemplo salgan nuevas versiones de ese programa ejemplo las del carrito, 1.0, 2.0, 3.0, etc. hasta que quede mejorada.
  • Es importante para saber que este software no tiene errores(o para lanzarlo con lo minimo de errores posibles).
  • El testing es importante ya que al ser "creado" por personas y máquinas ambas pueden llegar a cometer errores que no dejaría que la aplicación se pudiera utilizar de la mejor manera por lo que si un tester testea la aplicación y descarta errores que luego otros podrán corregir entonces el software no llegaría a manos del cliente con tantos errores logrando así que se lo pueda utilizar de la mejor manera.
  • Es importante el testing en el proyecto de sofware porque , a el crear un programa siempre hay fallas y el equipo de testing es el que se encarga de encontrar las fallas que pueda tener el mismo , y asi pasarle la imformacion e el equipo de desarolladores para reparar las fallas y mejorar el uso de las aplicacion , dandole asi un mejor servicio al cliente.
  • Es importante el testing debido a que sin el nuestro proyecto(software) no cumpliria nuestros objetivos estaria muy o totalmente defectuoso y no daria buena imagen ni convenceria a ningun usuario y/o cliente de usarlo.
  • Es importante ya que de esta forma podemos ver los bugs que este tiene y de esa forma podemos sacar al mercado el software con un mejor funcionamiento y así sera mejor para el o los usuarios.
  • Es importante porque el testing es el que reporta los bugs y asi el desarollador pueda reparar esos bugs.
  • Es importante porque nos permite encontrar a tiempo distintos errores de diferentes magnitudes que pueden afectar a dicho software. También se pueden realizar sugerencias para la mejora del mismo.
  • El testing es importante porque ayuda a los programadores a probar el software y encontrar errores y asi poder sacarlo con los menos errores posible.
  • La importancia de testear software es que al momento de lanzar un producto al mercado, nos aseguramos de que los margenes de error que pueda tener ese software sean menores, es decir, que el programa/aplicación funcione de la manera mas correcta posible, y el resultado de eso es posible, gracias al conjunto de pruebas realizadas por nosotros.
  • SI no se hace un testing en un proyecto de software, y es lanzado sin ser testeado, el proyecto podría tener muchos errores y algo con errores no gusta ni al dueño del proyecto ni al usuario que después lo usara. El testing sirve para buscar errores, comunicárselo al desarrollador y así el pueda arreglar los errores, y el producto final salga lo mejor posible para agradar a dueño y próximos usuarios.
  • El testing es importante para cualquier proyecto de software porque básicamente comprueba todas las funciones del programa o aplicación. Prueba antes de que salga al mercado o uso del usuario. al testearlo puedes evitar que el software tenga bugs o algún problema que impida el correcto funcionamiento del software. Los bugs o errores pueden ser insignificante como errores de estética o pueden ser  de prioridad alta como el mal funcionamiento de la función mas básica del software.
Creo cada vez más que con el testing podemos mejorar la sociedad, educando a quien lo necesita, brindándole oportunidades que le permitan crecer, y a su vez, contribuir al rubro de la informática, sumando gente que haga fuerza en mejorar la calidad de las aplicaciones que todos usamos en el día a día. 

¡Qué lindo es ser parte de Nahual!
↧
Viewing all 48 articles
Browse latest View live
Search