Veamos en este post lo que nos falta ver en Gatling: la ejecución y reportes de pruebas de performance. Uno de los aspectos interesantes de esta herramienta está en los buenos reportes que nos brinda luego de ejecutar las pruebas. Ya estuvimos viendo un resumen de la herramienta, cómo grabar scripts y cómo editarlos. Ahora la parte más entretenida, la ejecución.

Para ejecutar el script que preparamos con Gatling, simplemente se ejecuta /gatling.bat. Primero nos preguntará qué archivo queremos ejecutar, y luego nos dará la posibilidad de ingresar un identificador y una descripción para la prueba. Cuando comienza a ejecutar nos muestra una pantalla como la siguiente, donde resume las principales métricas obtenidas hasta el momento:



Al finalizar nos indica dónde nos deja el reporte HTML.

Reportes en HTML

El reporte que muestra como resultado al final de la prueba es realmente muy bueno. Es colorido, prolijo, con mucha información bien presentada y fácil de navegar.

En primera instancia muestra un resultado bien fácil de entender de cómo resultó la prueba, en cuanto a respuestas fallidas, y en cuanto a distribución de los tiempos de respuesta:


Luego muestra la estadística completa de todas las peticiones realizadas, tanto las primarias como los recursos embebidos, mostrando los que fallaron y los que pasaron las validaciones, así como un desglose de los tiempos de respuesta considerando no solo promedio, sino que también los distintos percentiles:


Se muestra un resumen de los errores encontrados:



Cantidad de usuarios activos durante la prueba:



Los tiempos de respuesta obtenidos durante la prueba:



Encuentro muy útil que en la primera se combinen los tiempos de respuesta, así como los requests que fallaron. En la segunda muestra un detalle de los tiempos en cuanto a los percentiles, pudiendo ver dónde se concentraron la mayoría de los tiempos de respuesta en cada intervalo.

Una novedad para mí, es que además de mostrar los requests/segundo también muestra los responses/segundo.

Es interesante observar que con la barra gris que está debajo de cada gráfico se puede hacer zoom en ellos para focalizar y analizar en detalle en determinados puntos de la prueba. En estas gráficas también es interesante ver cómo cruza la información de transacciones por segundo con la cantidad de usuarios activos durante la prueba.

Algo que también está bien útil es definir grupos, de forma de poder agrupar y sumarizar los tiempos de distintos requests. Así, dentro del grupo quedan anidados todos los pedidos relacionados. Esto nos lleva a una buena práctica de definir un grupo para cada paso, a pesar que tenga un solo request, ya que de esta forma vamos a poder tener los tiempos de respuesta de toda una página, incluyendo sus recursos embebidos.

Entonces, si cambiamos el script y lo reestructuramos de esta forma:

Obtendremos un reporte mucho más fácil de navegar aún:



Donde cada uno de los pasos se puede ampliar y ver el detalle por cada request.

Toda esta información se puede ver en detalle para cada “request” como para refinar el análisis yendo a la pestaña “Details” en la parte superior del reporte.

Lo único que veo que le estaría faltando, que es bastante común en otras herramientas, es el resumen de los datos transferidos durante la prueba. Esto igual se puede obtener fácilmente con monitorización a nivel de red en la generadora de carga.
Otra limitante muy grande es que el reporte lo puedo ver al finalizar la prueba. Durante la ejecución no hay forma simple de ir viendo cómo va.

Performance de la herramienta 

Parece chiste, pero es muy importante conocer cuál es la performance de la herramienta, para poder determinar cuántos usuarios concurrentes se pueden ejecutar por máquina. En la página del producto dice que gracias a que usan un mecanismo asincrónico no bloqueante, la herramienta tiene un alto rendimiento. Me queda pendiente la tarea de hacer un benchmark entre Gatling y JMeter, espero poder hacerlo más adelante y compartirlo.

Por otra parte, una estrategia muy utilizada en estas herramientas para poder escalar la cantidad de carga generada es la de distribuir el trabajo entre distintas máquinas, siguiendo un esquema maestro-esclavo. O sea, se distribuyen los usuarios virtuales a generar entre distintas máquinas, donde hay una que centraliza la coordinación y gestión, así como los resultados. La limitación más grande en este sentido es que no escala horizontalmente. O sea, no tiene la posibilidad de distribuir la carga entre varias máquinas.
En la documentación muestran un mecanismo para poder escalar que también me queda pendiente probar. Lo pueden ver aquí, donde básicamente plantean armar un script para invocar de manera remota y coordinada la prueba en cada máquina, y luego un truco para poder centralizar los distintos reportes en uno solo.

Por último, se puede escalar utilizando la nube de Flood.io o BlazeMeter (usando Taurus).

Resulta muy enriquecedor ver cómo otras personas realizan las pruebas exploratorias y las diferencias que hay entre uno y otro a la hora de llevar a la práctica este enfoque. ¿Qué elementos le resultan más importantes? ¿Qué registrar y qué no? Podemos encontrar algunas respuestas a éstas y otras preguntas que generalmente nos hacemos al enfrentarnos a las pruebas exploratorias. Por esto comenzaremos con una serie de posts en los que entrevistamos a distintos testers con experiencia en testing exploratorio, para de esa forma entender mejor las dificultades y necesidades de aplicar este enfoque. Queremos así poder compartir contigo los principales desafíos y aprendizajes de cada uno, así como también aprovechar a obtener más y mejor guía a la hora de diseñar Relytest (te dejamos este link donde hablamos del proyecto de construir esta herramienta opensource).

En esta primera oportunidad, te compartimos la experiencia de Iván Serrano, quien ha pasado por distintas empresas y proyectos, probando aplicaciones para start-ups hasta para grandes corporaciones. Iván ahora está más enfocado en el testing automatizado, pero cuenta con varios años de experiencia en testing exploratorio.

¿En qué oportunidades es recomendable utilizar el testing exploratorio?

Una de las dos situaciones en las que resulta sumamente útil el testing exploratorio, es cuando desconocemos un producto y queremos ver de qué se trata por primera vez. ¿Qué hace? ¿Qué es todo lo que puedo hacer? ¿De qué modo lo hace? Esta es una de las dos situaciones que destaca Iván, en general, cuando vamos a probar un producto por primera vez, ya sea una aplicación de escritorio, página Web o aplicación móvil, realizamos un primer acercamiento a sus funcionalidades mediante testing exploratorio. Este acercamiento puede resultar algo diferente de otras exploraciones en las cuales ya conocemos bien el producto. Es así que nos surgen muchas dudas que luego se traducen en preguntas al cliente para tratar de comprender qué es lo que debería hacer el producto y de qué modo.

Comencemos por el principio

Iván realiza testing exploratorio basado en sesiones. Lo primero que él hace es definir las misiones, si estas no vienen definidas por le líder de Testing. Lo hace con un enfoque basado en riesgos y decide el largo de cada sesión en función del conocimiento que tiene de la aplicación. Si tiene conocimiento dedica, en general, unos 15 minutos, ya que las sesiones son bien específicas. Cuando no tiene conocimiento estima unos 60 minutos.

A la hora de ejecutar

Al momento de la ejecución, cierra la casilla de correo, apaga todas las notificaciones y comienza a correr el cronómetro. Ivan destaca que ¡es muy importante que el cronómetro esté visible siempre! Además, comenta que mejor que no tenga sonido, ya que el sonido distrae, y que avance hacia adelante, no hacia atrás. También destaca la importancia de poder poner pausa en el cronómetro, si bien entendemos que la sesión constituye la ejecución de un objetivo en una unidad de tiempo ininterrumpida, debemos tener la flexibilidad suficiente para considerar eventos que impliquen una breve interrupción, como por ejemplo, ir al baño :P

Lo primero es completar las áreas, las cuales incluyen la siguiente información: el ambiente, la plataforma y las estrategia. En su caso utiliza un enfoque basado en riesgos, además incluye la investigación y reporte de incidentes realizando exploración y observación.

Las observaciones en las notas le sirven luego, entre otros, para derivar nuevas misiones.

¿Qué hacemos cuando no sabemos cómo seguir?

A veces sucede que comienza a ejecutar una misión y descubre que hay pasos intermedios de los que no tiene conocimiento cómo funciona la aplicación, o que debe realizar ciertas acciones con anterioridad para poder ejecutar esa misión. En ese caso, interrumpe la misión detallando las razones de dicha interrupción y dando por terminada esa instancia. Luego de investigar lo que desconoce o realizar los pasos previos retoma esa misión de cero.

Métricas de las sesiones

Al final completa las métricas propuestas por los hermanos Bach. Trata de balancear misión y oportunidad. Una sesión donde la oportunidad sea mayor al 60% carece de sentido. Es necesario renombrar esa misión con lo que realmente se ejecutó.

Completa también la sección archivos, donde incluye toda la información analizada previamente como ser documentación existente, especificaciones, manuales, etc. Toda esta información constituye además un input para la redacción de las misiones. Incluso define datos de prueba, los cuales incluye luego en esta sección.

¿Y las notas?

La pregunta del millón: ¿Qué poner en las notas? Esta es una dificultad frecuente, más aún, en los que recién comienzan a realizar testing exploratorio. Bueno, Iván nos cuenta que él va registrando los pasos que va realizando y los pensamientos que le van surgiendo. Entiende que las notas se deben escribir siempre en primera persona. Y de éstas derivan luego manuales de uso de la aplicación, información para otros testers, y especificación de casos de uso entre otros. Además, nos muestra su forma de registro, no lo va haciendo continuamente, sino que cada aproximadamente 3 minutos, que es lo que puede recordar sin mayores dificultades, pasa al formulario de registro a completar todo lo que hizo en ese tiempo, sus pensamientos, etc.

En la sección de defectos registra el ID del incidente reportado en la herramienta de gestión que corresponda. Luego, en la sección de inconvenientes, nos da algunos ejemplos de qué registrar: “se cortó internet”, “me llaman a una reunión”, etc.

Nos comenta, además, lo interesante que sería que la herramienta permitiera taggear las notas para poder identificar fácilmente de qué estamos hablando.

Respecto a la captura de imágenes durante la sesión, la realiza únicamente al detectar incidentes. La edición de las imágenes, si bien lleva tiempo, es parte de la sesión, por lo que debe realizarse durante la misma. Respecto a la utilidad de incluir videos, nos comenta que le puede resultar interesante sólo cuando los pasos para reproducir y las capturas de pantalla no resultan suficientes. También indagamos sobre la utilidad de realizar el registro mediante audio, pero él nos desaconseja esta opción debido a la dificultad y el tiempo que lleva su análisis posterior.

¿Cómo se sigue después que terminamos la sesión?

Luego, sobre el final nos comenta dos aspectos que nos resultan sumamente interesantes. El primero va de la mano con la propuesta de debriefing de James Bach, o sea, el análisis posterior de las notas. Este análisis debería ser realizado por la misma persona que tomó las notas. En su operativa, él realiza el análisis y como resultado elabora un resumen de las notas. El objetivo del resumen es facilitar la información recolectada para su posterior utilización ya sea en la redacción de manuales, trasmisión de conocimientos adquiridos a otros testers, etc. El segundo es la inclusión de dos o tres preguntas que permitan recoger la experiencia del tester en lo referente a usabilidad y experiencia de usuario. Por ejemplo,¿qué te pareció la navegabilidad?

RelyTest, consideraciones para la herramienta

Gracias al apoyo de Iván hemos considerado muchos de estos aspectos en nuestros primeros prototipos. Hoy en día, RelyTest ya incluye las siguientes funcionalidades:

• Cronómetro:
• Hacia adelante.
• Sin sonido.
• Con posibilidad de pausarlo.
• Notas taggeadas.
• Capturas de pantalla, se salvan automáticamente las imágenes dando la opción configurable de abrir el editor por defecto cada vez que se toma una imagen. De este modo se puede editar rápidamente la imagen en el momento.

Otro de los objetivos del proyecto: la metodología

En lo que se refiere a la metodología, aún en investigación, se considera fundamental el registro del análisis realizado por la persona que ejecuta la sesión, o sea, el resumen de la misma. Siendo el resultado de éste lo que enriquece el conocimiento adquirido del producto ya sea para uno mismo en próximas ejecuciones, trasmisión de conocimientos entre miembros del equipo o para una integración más eficiente de nuevos integrantes al equipo.

El Testing y la Calidad

Ya para cerrar Iván nos comparte su concepto y reflexión sobre la calidad y testing: “Cada persona en su naturaleza tiene una capacidad crítica, única, su propia espontaneidad, una forma de ver las cosas, más allá de las convenciones necesarias para coexistir con el entorno. Creo que el testing como actividad, debe siempre intentar que esa naturaleza no se reprima. El testing exploratorio, dentro de las actividades de testing, es el enfoque que más conserva dicha naturaleza, por lo que todo lo que derive de él, siendo sistematizado y ordenado de manera correcta, no es más que un conjunto de riquísimos aportes a la hora de garantizar la calidad de algo, ya sea un producto derivado de la tecnología de la información, o yendo más allá aún, como las cosas más comunes y cotidianas de la vida. La búsqueda de la calidad la entiendo como aquella búsqueda que enriquezca de la mejor manera y más equitativamente posible al conjunto de personas que la van a ser beneficiados por la misma.”

¿Quién es Iván Serrano?

Entré al mundo de la informática por el lado del diseño gráfico. Conocí la actividad invitado por Cesar Ganduglia en Celta Consulting, quien me invitó a capacitarme y realizar mis primeras incursiones en el Testing, trabajando para Volt Uruguay (Páginas Amarillas). Luego realicé un impasse en el área tecnológica para dedicarme al área social como Educador Social, estudiando para ello y realizando varios cursos especializados en violencia doméstica y primera infancia. Retorné al mundo de la informática trabajando para Globant, recomendado por un amigo, Germán Bernardez. Allí trabajé para diversos proyectos como K12, Tenaris, Southwest Airlines, BBVA API Marketplace entre otros. En estos proyectos apliqué siempre que pude el testing exploratorio como enfoque y enriquecimiento de pruebas. Trabajando en Globant conocí a Andrés Curcio, de quien aprendí mucho sobre testing y fundamentalmente de testing exploratorio. Actualmente me desempeño en Abstracta como QA, trabajando para proyectos como Stampr, Worscom y Verifone, donde también he podido utilizar el testing exploratorio como parte fundamental del enriquecimiento de las diversas actividades que atañan al Testing.


¡¡Muchas gracias por tus invaluables aportes Iván!!

En este post seguimos en la línea del anterior, en el que estamos entrevistando distintos testers de nuestra comunidad para ver cómo prueban, qué desafíos enfrentan, y así poder ir delineando mejor la herramienta opensource llamada RelyTest que estamos preparando. De esta forma esperamos poder contribuir también intercambiando experiencias y así poder aprender todos un poco más a partir de nuestra comunidad. En esta ocasión, hicimos una entrevista a Lisandra Armas (senior tester en Abstracta, experta en test de accesibilidad) en simultáneo mientras realizaba una exploración sobre la aplicación que está probando actualmente.

Está probando una aplicación que se va desarrollando bajo un marco de gestión ágil. A medida que las funcionalidades se encuentran más estables ella realiza sus pruebas. No intenta abarcar todo sino que se enfoca en determinadas funcionalidades cada día. Encontró que de este modo le rinde más el tiempo, encuentra más bugs al enfocarse en algo particular que si quiere probar todo en la misma sesión.

Testing basado en sesiones

Nos va contando de su experiencia con testing exploratorio mientras continúa ejecutando. Realiza pruebas exploratorias basadas en sesiones, al igual que Iván. Nos cuenta que le lleva un tiempo completar el formulario con toda la información que se solicita, nos comenta que tomar sus notas e ir registrando lo que va haciendo, le llevan casi el mismo tiempo que ejecutar la aplicación. Tomar las notas de este modo le resulta tedioso y hasta le da pereza pensar en las pruebas exploratorias con el solo hecho de saber que va a tener que escribir todo el tiempo lo que está haciendo.

Nos comenta Lisandra que no le encuentra un valor claro a las métricas utilizadas en las sesiones exploratorias como suelen trabajarse habitualmente. Le es necesario valerse de otros aspectos de las pruebas para poder gestionarlas apropiadamente y mostrar su avance al equipo.

En general, considera sesiones cortas, de unos 20 minutos. Para tener noción del tiempo utiliza un timer online: timeanddate.com. Al cumplirse el tiempo marcado al inicio esta página web le muestra un popup con la alerta. Le resulta útil que tenga sonido, a diferencia de lo que nos decía Iván, que el sonido lo distraía. Vamos viendo las pequeñas diferencias que surgen al llevar a la práctica el testing exploratorio.

Mientras hacemos la entrevista Lisandra nos muestra cómo ejecuta. En determinado momento se da cuenta que se olvidó de arrancar el cronómetro. “Es que son muchas cosas”, comenta. Observo cómo va escribiendo lo que va haciendo a la par que realiza las pruebas, cambiando continuamente de pantalla. Resulta bastante agotador el mecanismo. Veo que registra entre comillas los campos de la aplicación que va completando con datos, y los datos a continuación.

¡Encontrando y reportando bugs durante la entrevista!

¡Encuentra un bug! Entonces, saca una captura de pantalla, utilizando la herramienta Greenshot. Selecciona la sección donde está el error y guarda en el escritorio en una carpeta bugs (donde están todos los bugs del proyecto). Al reportar el incidente re-escribe los pasos (no utiliza la información que tiene en las notas de la sesión) y adjunta la imagen. Agrega resultado actual y resultado esperado en el reporte.

¿A qué se refiere la sección de riesgos?

Lisandra nos da algunos ejemplos de lo que serían riesgos en el contexto en el que ella está trabajando. Por ejemplo un riesgo sería que el usuario no entienda cómo realizar una determinada funcionalidad, por ejemplo que el usuario final puede no percatarse de que tenga que adjuntar una foto, teniendo en cuenta que dicha opción, si bien está disponible, se encuentra muy pequeña y podría ser difícil de visualizarla. Además, Lisandra tiene un background importante en todo lo que es accesibilidad de las aplicaciones, entonces comenta: ¨La opción está de color gris encima de un fondo gris¨.
Lisandra nos cuenta que tanto los inconvenientes como los riesgos los comunica o bien por Slack o bien en persona a los diseñadores que son los que gestionan los posibles cambios que pueden realizarse en la aplicación.

¿Cómo crear las misiones?

Primero prueba lo que liberan en el día, en función de eso crea las misiones. Si son cosas muy cortas, no crea una sesión sino que trabaja con un mapa mental.
Vuelve a mencionar algo bien interesante a tener en cuenta en el desarrollo de la metodología: ¨Se me van las ganas de probar sabiendo que voy a tener que escribir una sesión. ¨

Registrando las sesiones con mapas mentales

Siguiendo con el pienso de las misiones, nos cuenta que un día armó un mindmap de toda la aplicación, de todas las funcionalidades de ésta, sin llegar a un nivel tan profundo como los botones de aceptar o cancelar. Luego, registraba con distintos estados cómo se encontraban esas funcionalidades una vez probadas. Los estados que consideró fueron los siguientes: No funciona (o sea, no están desarrolladas aún, a las que le asignó el signo de interrogación: ?), Correcto (marcadas con un tick verde), Bug (marcadas con una ´x´ roja). Los bugs los registra en el mismo mindmap indicando con una nota los detalles de éste.

Al utilizar mapas mentales, crea un mapa por sesión. Estas sesiones podían a veces durar hasta 2 días cuando se está mirando la aplicación completa. Lo que realiza de ese modo es una regresión de la aplicación. En lugar de utilizar sesiones, como las descritas anteriormente, registrando en un archivo, el utilizar mapas mentales le resultó mucho más cómodo y más motivante al pasar más tiempo probando en lugar de registrando. Le gusta más la herramienta XMind que Mindmup (que funciona online en el navegador) porque puede trabajar sin conexión a internet.

Las notas que se registran durante la sesión, ¿para qué se usan luego?

Las notas le sirven como template para cuando prueba de nuevo esa funcionalidad cambiando algún dato puntual. O sea, toma una sesión vieja y la edita, de este modo no pierde tanto tiempo escribiendo y puede probar más.

¿Qué ventajas te proporciona el testing exploratorio respecto del planificado?

Al dominar la aplicación le rinde más hacer testing exploratorio que diseñar y ejecutar casos de prueba. Hoy en día ella tiene buen conocimiento del negocio y domina la aplicación, además de que la aplicación que está probando se encuentra más estable. Todos estos puntos favorecen a su entender el uso de un enfoque de pruebas exploratorias.

¿Cómo reportas los resultados de las sesiones ejecutadas?

Actualmente envía un reporte diario que contiene la siguiente información:

• Fecha.
• Tarea (donde detalla el tipo de tarea realizada, si fueron pruebas exploratorias, ejecución de casos de prueba, re-test  para validar resolución de bugs, etc.).
• Los bugs reportados, con su prioridad y la pantalla de la aplicación donde se reproduce ese bug (indicando claramente el nombre de la pantalla). 

En el reporte, incluye además, la planificación para el día siguiente.

¿Quién es Lisandra Armas?

Me gradué de ingeniera informática en la Universidad de las Ciencias Informáticas (UCI) de Cuba. Mi primera experiencia de trabajo como profesional fue en el Centro Nacional de Calidad de Software (CALISOFT) donde realicé pruebas funcionales, testing exploratorio, pruebas de usabilidad, rendimiento y accesibilidad en diversas aplicaciones web, desktop y multimedias educativas. Me encuentro actualmente trabajando en Abstracta y en este tiempo mi trabajo ha girado entorno a las pruebas en dispositivos móviles, donde he incrementado mi experiencia en testing funcional y automatizado, usabilidad, accesibilidad y testing exploratorio enfocado a aplicaciones móviles en clientes cómo Código del Sur, Overactive, Blue Cross & Blue Shield. He realizado publicaciones de artículos de testing referentes a las pruebas de software, pruebas en dispositivos móviles y pruebas enfocadas a la accesibilidad en la web y mobile. Mi pasión es el Testing, aplico testing exploratorio por las ventajas que proporciona, dónde puedo realizar de forma simultánea el aprendizaje, el diseño y la ejecución de las pruebas a lo largo del desarrollo del proyecto.

Tal como lo anunciamos un mes atrás, nos sumamos a la iniciativa de Rosie Sherry de Ministry of Testing, que propuso como desafío una serie de actividades de testing día a día. Aquí les comparto la experiencia de este mes en Abstracta siguiendo el desafío, y les aseguro que mis conclusiones son súper positivas.

En Abstracta varios nos sumamos a la movida, incluso organizamos grupos y teníamos un canal de Slack para ir compartiendo los avances de cada uno, imprimimos varias copias de los desafíos y las repartimos por toda la oficina. Estuvo muy bueno porque si bien lo marcamos como una competencia, en realidad nadie pensaba en ganar, sino que nos ayudamos bastante entre nosotros para varias tareas, y creo que todos aprendimos en el día a día de muchas cosas, nos exigimos para poder lograr llegar a cubrir este juego. Cada uno a sus tiempos, tal vez no en el día a día como estaba marcado, pero de vez en cuando actualizándonos con lo que se nos había quedado atrás. Algunas cosas las compartimos también por Twitter, lo cual generó más interacción con más gente incluso fuera de la empresa.

#30DaysOfTesting Si intento automatizar un sistema GeneXus con otra herramienta es complicadísimo! Mi tool favorita es @GXtest por lejos! :)

— Giulliana (@giulliana_psv) July 22, 2016

#30daysoftesting#day22 My favourite testing tool is @Monkopapps Give it a try here https://t.co/7HKmbOyICY@ministryoftest

— Federico Toledo (@fltoledo) July 22, 2016

#30daysoftesting designing how to help lots of new students test better https://t.co/Cz4jGi8sKR

— Federico Toledo (@fltoledo) July 23, 2016

Los invitamos a todos al Slack de TestingUY, para estar más conectados y poder conversar entre todos, generando discusiones, debates, intercambiando información, herramientas, piques y mucho más.

Slack es una forma más en la que queremos acercar a la comunidad y facilitar las interacciones entre todos los miembros. Es un espacio que facilita la interacción, la conversación pública en grupos, o entre distintas personas.

La comunidad de Slack de TestingUY está accesible aquí: http://bit.do/slacktestinguy.
Simplemente ingresá tu email y ya podrás conectarte a http://testinguy.slack.com.


Una vez que ingresás, verás una pantalla como la siguiente:

• TestersIO de Europa, organizada por Rosie Sherry de Ministry of Testing. 
• TestingAr Meetup, organizada por varios amigos de la comunidad de testing de Argentina, localizado principalmente en Buenos Aires. 

Las próximas semanas se vienen intensas con actividades en distintas conferencias en Montevideo. Aquí les dejo la invitación a cada una de ellas:

Encuentro GeneXus

Como todos los años desde nuestro arranque estaremos haciendo que el testing esté presente en el Encuentro GeneXus, en el Radisson Montevideo Victoria Plaza Hotel.


Nuestras participaciones serán:

• Lunes 26/09, 12:15hs - Florida Room. Lisandra Armas, ¿Cómo hacer que nuestras aplicaciones GeneXus mobile sean más accesibles?
• Martes 27/09, 9:00hs - Renoir Room. Arcadio Abad, El secreto de automatizar cuando no tenemos tiempo para hacerlo.
• Miércoles 28/09, 11:00hs - Diplomat. Estaré junto a otros amigos coordinando el Café con Testing de Software. 

El día siguiente al evento estaremos brindando una capacitación de 4hs de Pruebas de Performance con JMeter y BlazeMeter, aprovechando las facilidades que brinda GXtest para eso. Este curso lo brindaremos junto a Arcadio Abad y Leticia Almeida, el jueves 29/09 de 9 a 13hs. Para inscribirse comunicarse a talleres@genexus.com (info aquí).

Además aprovecho a comentar que Nahual (emprendimiento social y solidario en el que colaboro) estará participando con una charla también:

• Lunes 26/09, 11:45hs - Florida Room. Laura Aguiar y Rodrigo Gómez, ¿Buscas testers? Ellos buscan una oportunidad.

NetConfUy

El sábado 1º de Octubre, junto a Fabián Baptista, estaremos dando una presentación llamada ¿Cómo asegurar la performance de aplicaciones móviles tanto en el device como en el servidor? a las 16:40 en el track Octopus, en el Auditorio de Antel.

ExpoLearning

Luego tendremos lugar a compartir los desafíos y las lecciones aprendidas al construir cursos online para testers, con lo cual estaremos hablando de Abstracta Academy. Esta charla será el 5 de Octubre en la Torre de las Telecomunicaciones (Sala Idea Vilariño), y la daremos junto a Gabriela Sánchez.




¡Espero que sean de su interés y nos veamos por ahí!

Desde el 2017 comenzamos a enfocar nuestros esfuerzos en dos blogs, separando los contenidos por idioma.

• Para ver nuestros nuevos contenidos en español, accedé a www.federico-toledo.com
• Para ver nuestros nuevos contenidos en inglés, accedé a www.abstracta.us/blog