Abstracta Blog

Apuntes sobre Usabilidad

2012-02-09T10:39:00.000-08:00

Si bien no soy experto en este tema, siempre me llamó la atención y me interesó conocer y leer al respecto.

En el congreso al que fui el el año pasado (VLCTesting) se dio una charla muy buena de usabilidad. Se contó acerca de un experimento que hicieron con distintas personas mientras utilizaban un sistema por primera vez, en el que capturaban las pantallas y filmaban al mismo tiempo todo lo que los usuarios hacían, para luego analizar el comportamiento. Además le habían pedido al usuario que relate su proceso mental, o sea, que vaya contando lo que estaba haciendo, qué estaba buscando, qué cosas no entendía, etc. Me parece una práctica muy interesante que permite descubrir un montón de cosas sin ser siquiera experto. Permite entender qué cosas son las que complican a alguien para entender el sistema ante la primera vez que lo utiliza, pues, dentro del equipo de desarrollo esa visión se pierde, incluso con el equipo de testers, ya que tenemos sólo una oportunidad por persona de la "primera impresión". Luego, ya habremos aprendido y aceptamos las cosas tal como están, y nos dejan de parecer poco naturales o extrañas. Recuerdo que José Lamas alguna vez nos planteó un ejercicio similar incluso con nuestro desarrollo y nos dio buenos resultados.

Otra cosa con la que me quedé de la charla, es que recomendó este libro: No me hagas pensar, de Steve Krug. Luego que lo lea les comentaré, y si alguien ya lo leyó que quiera aportar algún comentario, bienvenido!

Otro tema que me resultó muy interesante que lo comentó un profesor en las clases de master, es la que llamó la regla del número 7, que dice que es un número muy importante, como por ejemplo la cantidad de cosas que puede llegar a recordar el cerebro en corto plazo, por lo que es un número muy importante a tener en cuenta para temas de usabilidad. Por ejemplo, ¿cuántas pestañas tiene la nueva barra del Office 2010? y ¿cuántos grupos de elementos hay en cada una?, curioso, ¿no?.

Acá en Uruguay existe una empresa (cuyo nombre es el antónimo al de nuestra firma) llamada Concreta que son apasionados por estos temas y brindan servicios relacionados. En su página puden encontrar varios artículos interesantes para quien le interese leer un poco más del tema. También pueden encontrar más información en el blog de Daniel Mordecki.

Si quieren ir leyendo algo más al respecto les recomiendo este link. ¿Alguien tiene algo para recomendar?

Tests de Performance en GeneXus

2012-01-27T08:14:00.000-08:00

Si alguna vez intentaron hacer pruebas de performance sabrán que no es una tarea que se haga de la noche a la mañana, y generalmente llevan mucho esfuerzo, especialmente para la preparación de las pruebas, donde lo más complejo (especialmente en sistemas desarrollados con GeneXus) es la automatización de los casos de prueba.

Finalmente estamos anunciando la liberación de una nueva funcionalidad de GXtest que permite generar pruebas de performance en tiempo record, más rápido que con cualquier otra herramienta, con las facilidades que brinda GXtest, permitiendonos así simular la realidad a la cual se quiere poner en producción el sistema con buena fidelidad.

En muchas situaciones, tales como cuando nuestro sistema debe estar accesible para muchos usuarios que trabajan simultáneamente sobre el servidor, o si ciertas operaciones deben ser resueltas en determinados tiempos de respuesta, o bajo cierta cantidad de recursos limitada, no hay otra que hacer una prueba de performance. Es la única forma en la que podemos verificar cómo se comportará nuestro sistema, mediante una simulación de la carga con el uso de las herramientas adecuadas.

Los principales motivos por los cuales nos puede interesar evaluar el rendimiento de nuestro sistema son:

Poner en producción un nuevo sistema
Cambiar la tecnología (ej. migrar de Win a Web)
Cambiar el hardware, arquitectura, DBMS o SistemaOperativo de algún componente
Liberar un cambiosignificativo en la aplicación

Los beneficios:

Determinar el hardware mínimo necesario para soportar las necesidades.
Conocer y así controlar:

Tiempos de respuesta,
Consumo de recursos (CPU, Memoria, Disco, red, etc.)
Interrupciones de servicio
Recuperación a fallos

Hasta hoy, para automatizar testing funcional de apliacaciones GeneXus usamos GXtest. Para testing de performance seguíamos teniendo un gran problema al usar las herramientas tradicionales. Dado la forma en la que trabajan las herramientas que permiten realizar este tipo de simulaciones, los scripts (casos de prueba automatizados) quedan muy sensibles a los cambios de la aplicación. Esto es: introduzco un pequeño cambio en el desarrollo o cambio la versión de GeneXus, y los scripts quedan casi inservibles (problemas de mantenimiento de scripts) teniendo que rehacerlos por completo.

GXtest Professional libera una nueva funcionalidad ya probada en varios proyectos con éxito:

GXtest2OpenSTA, que permite a quienes desarrollan con GeneXus usar una herramienta como GXtest para hacer testing de performance.

Permite preparar los scripts de pruebas mucho más rápido y fácil, brindando la facilidad de generar scripts que se alimenten de distintos juegos de datos, validen las respuestas de la aplicación, simulando las acciones del usuario, para que luego GXtest genere los scripts ejecutables en OpenSTA con pedidos http en forma automática.

El top 3 de beneficios:

Reducción de más de un 80% de construcción de los scripts OpenSTA. (para casos complejos mucho más aún)
Permitir ajustar cambios en desarrollo / tunning y volver a regenerar
Reducir drásticamente la complejidad de realizar y entender los scripts, y los diferentes pedidos de la aplicación

Les dejo un video de cómo se generean los scripts y cómo se ejecuta la prueba:

Aquí encontrarán información de para qué y cómo realizar scripts de carga para sistemas GeneXus usando GXtest.

Estamos muy contentos con este gran avance que nos permite resolver necesidades de nuestros clientes en tiempo record, solucionando problemas de performance, ofreciendo un mejor servicio, logrando que puedan liberar nuevos sistemas, nuevas funcionalidades, con mayor calidad, menor riesgo y menores costos.

Transferencia de conocimiento con el testing de regresión

2011-12-21T07:10:00.000-08:00

Quiero dejarles algunos comentarios de la forma en que nos vimos resolviendo dos cosas muy importantes que teníamos para hacer, en una combinación que creo que puede ser repetible en casi cualquier contexto:

Actualizar la información en el issue tracker
Capacitar a un nuevo integrante del equipo en aspectos varios de testing y de GXtest.

Usamos Mantis para gestionar los incidentes. La gran mayoría de los issues los reporté yo (al comienzo era el único tester), parte por clientes y otros usuarios. Por priorizar las pruebas de otros componentes o funcionalidades, muchas veces se deja de lado la verificación de la resolución de los incidentes. El ciclo que tenemos definido para los issues indica que luego que un desarrollador resuelve un incidente lo pasa a resolved y de ahí el que lo reportó lo verifica y puede pasarlo a closed o puede decir que aún no está solucionado. Entonces, teníamos muchos incidentes en estado resolved que estaban a la espera de que se verifiquen por un tester.

Hace poco incorporamos dos personas a nuestro equipo. En particular Leopoldo está más dedicado al testing funcional, y como suele suceder gran parte de su tiempo al comienzo está destinado a capacitarse, no solo en testing sino también en el producto que en este caso es GXtest.

Lo que buscamos fue una forma de que se capacite y a su vez genere valor, sintiendo además que está dedicando sus horas a algo que de frutos. Combinando estas dos cosas ¿qué nos planteamos?: revisar los incidentes en estado resolved y decidir si se podían cerrar o si se debían reabrir o revisar.

Objetivo planteado: 5 por día y verá que puede. La idea era no pasar todo el día revisando incidentes, sino que irlo haciendo en forma paulatina y con cierta constancia.
Resultados: positivos!

Sin buscarlo se superó la cantidad pensada de 5 por día. A medida pasa el tiempo se observa más agilidad e independencia para la revisión de los incidentes.

Se aprende de:

la aplicación y el dominio
de testing (en base a los reportes se pueden observar implícitamente las técnicas utilizadas, las cosas a las que se le pone foco, etc., y también lo efectivo o inefectivo de los reportes)

Otras beneficios obtenidos

se hizo una revisión por pares de los incidentes y de esa forma incluso yo terminé aprendiendo y observando mis errores, de cosas con las que no estaba siendo claro, etc.
se hicieron pruebas de regresión sobre incidentes marcados como resueltos
se prepararon reportes, los cuales nos permitió ver qué información resulta más útil mostrar para entender rápidamente el avance (en esto llegamos más que nada a cantidad de incidentes pendientes, clasificaciones por prioridades, por criticidad y por categorías)

Algunos números:
Comenzamos con 301 issues con estado resolved el 21 de Noviembre, y al 16 de Diciembre nos quedaban 169, reduciendo un 56,41%. Quedan 132 por revisar, (43,59%). De los 169 issues actualizados, 11 pasaron de Resolved a Open o Assigned, representando un 6,5% de los issues resolved actualizados, el resto (93,5%) se cerraron. Esto también muestra una efectividad en la corrección de incidentes (excelente Fabián y Matías!).

Esperemos poder seguir aportando datos desde nuestra experiencia, a medida veamos que ellos puedan ser útiles para alguien más. Genial si tienen ideas para contraponer o compartir.

Aprovechamos para desearles felices fiestas a nuestros lectores y un año nuevo de plena calidad!

Lo que fue el VLCTESTING

2011-11-17T05:31:00.001-08:00

Como les conté, fui al VLCTESTING, celebrado en Valencia.

El evento fue muuuy bueno! Unas 125 personas, mucho más de lo que habían pensado inicialmente los organizadores, en una ubicación muy buena, tanto por las instalaciones como por la ciudad.

La mayoría de las ponencias fueron sobre experiencias concretas en Testing y SQA, donde varias ponencias estuvieron muy interesantes, incluso una de usabilidad. Como hablábamos con Bea, en general muy buen ambiente, con gente interesada por el testing y con ganas de compartir conocimientos. De noche hubo un evento de networking también muy interesante (era en una cervecería, y nos invitaron con cerveza hecha ahí mismo, y con unas pizzas muuy buenas). Por las preguntas planteadas luego de las charlas, y por la gente con la que estuve conversando, adivino que en su gran mayoría eran testers, pero también habían desarrolladores interesados en mejorar sus prácticas en pro de la calidad.

Les dejo algunos links del grupo de testers de Barcelona que organizaron la parte de networking:

También agrego un link a un resumen del evento por si quieren ver de qué se trató cada charla, y aquí hay más aún, e incluso están las fotos del evento.

Un dato que me pasó Maximiliano Mannise (uruguayo, formado en testing en Uruguay, organizador del evento y director del Área de Calidad de Software del Instituto Tecnológico de Informática de Valencia) es que hubo mucha presencia de Uruguay en el evento, en la organización y en el escenario con un 20% de las ponencias. Creo que estamos dejando nuestra marca relacionada a la calidad no sólo a nivel nacional :)

VLCTesting 2011, Valencia, España

2011-11-07T15:27:00.000-08:00

El próximo jueves (10/11/11) se celebrará en Valencia el VLCTesting, organizado por el ITI, tratando temas de Calidad de Software y Testing. Ya hemos participado de muchos encuentros de este estilo en Uruguay, y tengo la curiosidad de ver si en España se vive de una forma similar, con las mismas interrogantes y necesidades, y ver si hay experiencias similares a las que nos enfrentamos en el día a día.

En el programa podrán ver que por parte de la UCLM va Beatriz Pérez, docente de Facultad de Ingeniería también, con la que trabajamos en el CES varios años, exponiendo sobre técnicas de testing combinatorio. Su aporte será desde la academia pero también habrán aportes de empresas, tales como Bull España o eXcentia.

Ya les contaré qué tal.

¿Cómo planificar la automatización de casos de prueba junto al desarrollo?

2011-10-28T11:15:00.000-07:00

En este post la idea es mostrar una posible forma de organizar la automatización, en base al plan de desarrollo, a modo de tener las pruebas automatizadas lo antes posible, sin perder de vista el test manual, y que las funcionalidades a automatizar ya deben estar testeadas.

Esto surgió en base a una pregunta de si tenía sentido automatizar las pruebas antes de que la aplicación esté lista. En nuestro enfoque, por ahora, no es la forma pensada de trabajo. Existen herramientas que plantean "automatizar" las pruebas antes de implementar, como para seguir algo de Test Driven Development. El tema es que esto puede llegar a ser un poco difícil de concebir, creo que aún falta mucho camino en cuanto a tomar conciencia y dedicar recursos para pruebas, y para automatización, como para priorizar este tipo de funcionalidades en GXtest. De todos modos, queremos compartir este approach que nos parece muy bueno.

Veámoslo con un ejemplo, en el que tengo un extracto del plan de desarrollo en el que se trabaja sobre 9 funcionalidades en 3 ciclos.

Lo importante a ver en el ejemplo es cuándo se hace cada tarea para un grupo de funcionalidades. Por ejemplo, sigamos las tareas para las funcionalidades F1, F2 y F3. En el primer ciclo se implementan y diseñan las pruebas. en el segundo ya se contará entonces con esas funcionalidades listas para probar, entonces las probamos, y luego las automatizamos. En paralelo con eso el equipo de desarrollo implementa las funcionalidades F4, F5, y F6, y se diseñan pruebas para ellas. En el siguiente ciclo, ya vamos a contar con las pruebas automatizadas para las F1, F2 y F3, entonces las ejecutamos. A su vez contamos con las pruebas diseñadas para las F4, F5 y F6, entonces las ejecutamos manualmente, y las automatizamos como para tenerlas para los siguientes ciclos. Observen que ya estamos ahorrando tiempo en ejecución de pruebas, y recién estamos en el ciclo 3!

Lo interesante bajo este esquema, es que quién automatiza (si son testers) podrían hacer ellos mismos el testing manual y en ese momento automatizar. Esto tiene como beneficio de que conocen la funcionalidad probándola, y luego al automatizarla les va a ir mejor. Es importante que en este punto al probarla manualmente decidan si la funcionalidad está apta para automatizar o si aún está muy "verde", dejándola para una etapa posterior, luego de las correspondientes correcciones.

Lo importante de este ejemplo es mostrar cómo planificar la implementación y la automatización de las pruebas. Acá no estoy considerando el diseño de la implementación, que tendría que ir un ciclo atrasado con respecto a la implementación. E incluso si quisiéramos seguir un modelo en V esto sería un poco distinto, las pruebas las definiríamos al mismo momento que los requerimientos, así que la parte de diseño directamente la sacaríamos de esta parte que ya sería al estar implementando.

Me gustaría conocer su opinión al respecto, y si tienen para compartir ideas, o formas de trabajo que puedan aportar al resto de la comunidad.

Mantener diseño de Test Cases lo más secuencial posible

2011-10-25T07:48:00.000-07:00

Alguien comentó en el MBTUC algo que me resultó interesante: los casos de prueba deberían ser lineales en el caso que los resultados sean deterministas, y sólo si tienen alguna variabilidad no definida de antemano agregar distintos flujos, pero lo mejor es mantener las cosas simples y secuenciales. Muchas veces los que venimos "del palo" de la programación tendemos a hacer casos de prueba tan genéricos que terminan siendo muy complejos.

En esto estamos bastante de acuerdo, y quiero comentar algunas cosas que hemos visto, como para que tengan en cuenta al momento de diseñar sus casos de prueba.

Si diseño un único caso de prueba que contempla distintas opciones, probablemente sea más difícil de entender, y para eso tenga que analizar qué se está consultando en cada decisión (bifurcación), qué se hace en un flujo u otro, etc., a menos que sea muy cuidadoso y llene el Test Case de comentarios que simplifiquen ese análisis. De todos modos, un test case secuencial con un nombre descriptivo da la pauta de qué es y qué hace.

Por otra parte, si el día de mañana agrego un nuevo caso, ¿dónde lo hago? ¿cómo agrego la bifurcación? ¿cómo manejo los datos asociados? Hacer test case nuevo, secuencial, con un datapool para ese caso, simplifica bastante esa tarea.

¿Que opinan al respecto?

GXtest Complex Flow

GXtest Simple Flow

Camino al Model-based Testing User Conference 2011

2011-10-25T00:18:00.000-07:00

En poco más de una semana dará comienzo este congreso de Testing Basado en Modelos, en Berlín, Alemania, al cual tendré la oportunidad de asistir.

Es la primera vez que se hace, así que no se puede decir que es un congreso que es importante por su historia, pero sí por el contenido del mismo. Pretende ser distinto al resto de los congresos de esta temática, ya que generalmente siempre son congresos académicos, mientras este intenta enfocar los aspectos de aplicación e ingeniería de este tipo de técnicas.

Es organizado por el European Telecommunications Standards Institute (ETSI) y por el Instituto Fraunhofer. El Instituto Fraunhofer es un instituto de investigación alemán que, como dicen en su página, tienen como fin principal orientar su investigación en las necesidades de la gente (the largest application-oriented research organization).

El programa se ve muy interesante. Hay charlas y tutoriales dados por líderes de testing de empresas como Microsoft y Nokia, de de importantes proveedores de herramientas y servicios de testing como ConformiQ y SmartTesting.

Hace unos años, en el Encuentro GeneXus del 2008, presentamos un prototipo de GXtest, y comenzamos la charla contando de qué se trataba el testing basado en modelos, como para luego mostrar cómo GXtest lograba aplicar esa filosofía en el mundo GeneXus, y por qué ese era el mejor enfoque para esta situación. El gurú que teníamos de referencia ya desde ese momento era el amigo Harry Robinson. El mismo estará exponiendo una charla en esta conferencia, y realmente es muy interesante tener la oportunidad de conocerlo y compartir el congreso con él.

Después les contaré qué tal todo.

Model-based Testing User Conference, Berlín - 2011

2011-10-21T04:31:00.000-07:00

Terminó la conferencia de MBT y lo mejor fue ver que en la industria, en grandes empresas principalmente, se está investigando e invirtiendo en estas técnicas de prueba para garantizar gran calidad de sus sistemas y reducir los costos del proceso de pruebas. El congreso fue de un gran nivel tanto en contenido como en organización, en una hermosa ciudad como lo es Berlín.

Las charlas principalmente mostraban herramientas disponibles en el mercado y casos de uso/éxito. Por ejemplo cómo Microsoft prueba Bing o Lync con estas técnicas (con su propia herramienta SpecExplorer), o cómo empresas como SAP, o Alcatel, Ericsson y Nokia, o Carmeq probando software automotriz para VW, Audi, etc. (les recomiendo ver la página que hablan de investigación en un auto que se maneja solo), o la empresa Giesecke & Devrient probando software embebido en un Cash Center (entre tanto, incluye esas máquinas que cuentan billetes a velocidad de 50 por segundo o algo así, detectando si hay falsos), etc. Estos últimos todos usando ConformiQ, modelando con máquinas de estado, implementando ellos mismos el test harness que sirva como capa de adaptación para invocar a sus sistemas, y lograr así que la misma herramienta sirva para todo tipo de interfaces. Tal vez más adelante me extienda en cada tema en distintos posts.

Hablando de autos, tengo que comentar que en Fraunhofer, y en Alemania en general, se investiga mucho en la industria automotriz, y por ende en el software que estos tienen embebido. Me llamó la atención entrar a la sala de conferencias y encontrarme un Ferrari deportivo ahí estacionado, teniendo en la matrícula la inscripción de Fraunhofer.

La charla de Harry Robinson fue más que nada divertida, es un buen orador, y lo presentaron como el pionero en el testing basado en modelos, contando por ejemplo que desde 1993 (creo) viene utilizando estas técnicas e incluso escribió sus primeros artículos y libros al respecto. En su charla contó que MBT no tiene que ser siempre una máquina de estados, sino que puede estar basado en otros modelos e incluso basados en heuristicas, pues algo que es cierto es que el resto de las presentaciones consideraron que el único modelo es una state machine para modelar el comportamiento esperado del sistema.

Otra reflexión que hago es que todos plantean construir un modelo de pruebas completamente independiente del sistema bajo pruebas, lo cual parece que agregara un gran costo en testing. Hoy en día creo que eso es algo que sólo las grandes empresas están haciendo (y muy pocas más por ahora), y según cuentan les da resultados sin grandes inversiones, entonces, deberíamos seguirlos, pero aún falta no se qué para terminar de convencer, o de mostrar que eso realmente funciona y que deberíamos adoptarlo.
Por otra parte, nadie considera seriamente la generación de pruebas a partir del sistema tal como lo hace GXtest Generator (que es nuestra parte de generación de pruebas con un enfoque puramente MBT). Se planteó en un momento la típica discusión de si generar pruebas a partir del sistema que querés probar te aporta, o si te estás haciendo trampa jugando al solitario, pero para eso nosotros ya tenemos una respuesta válida al menos para nuestro contexto, que es que si se encuentra un posible bug, no importa si es error del modelo de pruebas, del modelo de desarrollo, del generador de código o de la Java Virtual Machine, lo importante es detectar cada posible error que pueda llegar al cliente, corregirlo, y seguir buscando más errores.

Al final contaron estadísticas del evento muy interesantes, como que el 85% de los participantes eran de la industria y no de la academia, y también que asistieron alrededor de 200 personas, y de 4 continentes. Yo solito aporté en el 25% de esa última estadística :)
Esta fue la primera vez que se hacía este evento y por el éxito logrado planean desde ya repetirlo el año que viene. Pronto buscarán propuestas para ver dónde hacerlo, y esperemos poder asistir nuevamente pues considero que fue una experiencia muy enriquecedora.

PS: si alguien quiere algo del material que escriba un comentario y les mando

El encuentro vivido de afuera

2011-09-15T05:36:00.000-07:00

Esta es la primera vez que participo del Encuentro a la distancia, y si bien no fue lo mismo, creo que lo aproveché y disfruté bastante. Seguramente este año fue mucho mejor que si me hubiera tocado años anteriores, pues había transmisión en vivo de las principales salas (a pesar que en algunas a veces andaba muy lento), twitter está más movido que nunca (obviamente relacionado al crecimiento de SD que nombró @njodal), y que hay muchas más personas que lo viven de lejos como esta vez me tocó a mí.

Otro tema tal vez es que como no daba charla este año no estaba con el nerviosismo típico esperando a ver cómo sale, y ajustando últimos detalles. O sea, si bien colaboré a la distancia con mis amigos abstracteros, no era yo el que se paraba frente al público este año, y por eso miré más charlas más tranquilo. Lo bueno es que es más fácil moverse de una sala a la otra, lo malo es que no te encontrás amigos y colegas por los pasillos.

Estuvo genial ver el notorio crecimiento de ponencias relacionadas con testing de software. Además de las que presentó Abstracta y el CES, hubieron dos charlas de GXC (generalmente hay una) y a eso le sumamos la de GXunit y el clásico café con testing (ese sólo pude ver fotos y escuchar repercusiones al respecto --no estaría bien que también filmen ese, e incluso que haya un vocero que de vez en cuando plantee alguna cuestión interesante aportada por alguien que sigue por twitter??--).
De estas charlas me gustaron en particular dos cosas (no voy a hablar de las de Abstracta, de eso me gustó todo :P), primero la cantidad de profesionales del testing que vamos a tener gracias a la carrera del CES, excelente! mucha gente capacitada para aportar a la calidad del software que se produzca (principalmente) en Uruguay; y por otro lado GXunit, que me parece que es una idea que viene desde hace mucho y que por fin parece que se logró algo bastante bueno (no digo que los intentos anteriores fueron malos, sino que se dieron otras cosas como la estabilidad actual de la extensibilidad de GeneXus por ejemplo). Es una herramienta que permite al desarrollador automatizar pruebas implementadas en lo que sabe hacer, código GeneXus, integrada al IDE, fácil de usar, potente, y gratis! Espero la comunidad la adopte rápidamente.

El año que viene espero poder estar por ahí compartiendo y viviendo el encuentro otra vez desde cerca.

Por último les dejo links a todas las charlas relacionadas a testing, por si quieren ver los videos o las diapositivas:

Introducción a GXtest. (Fabián Baptista - Abstracta)
Automatizando Test, un año de experiencia con GXtest. (Juan Martín Anollés, Federico Alvarez - Concepto)
GXC Development Framework: Experiencias de testing y resultados obtenidos. (Matías Reina Abstracta, Carolina Torrado - GeneXus Consulting)
Roadmap de GXtest. (Fabián Baptista - Abstracta)
Todo sobre testing y más, en una Carrera. (Mariana Travieso, Mónica Wodzislawski - Centro de Ensayos de Software, Úrsula Bartram, Alejandro Blengio - Artech)
Probar GeneXus code con GeneXus code. (Nicolás Carro, Juan Pablo Goyeni, Marcos Olivera - Facultad de Ingeniería, Universidad de la República)
GXC Development Framework: Test de Aceptación, Do It! (Guillermo Skrilec - GeneXus Consulting)

Se viene el XXI Encuentro GeneXus

2011-09-09T07:07:00.000-07:00

Estamos muy cerca del comienzo, sólo a un fin de semana para le encuentro anual de la comunidad. Cada año estamos con más participación, lo cual nos gusta mucho, y por eso es que invitamos a los que van en especial a las siguientes actividades y exposiciones:

Introducción a GXtest. Lunes de 14.30 a 15hs. en el salón 2C (ballroom C). A cargo de Fabián Baptista, especialmente orientada a los que se quieren iniciar en el uso de la herramienta para automatización de pruebas funcionales para GeneXus. (#GX2405)

Laboratorio de GXtest. Lunes de 15.45 a 16.45hs. en el salón 4P (sala Picasso). A cargo de Leopoldo Flanagan, se verán en práctica las funcionalidades de GXtest. Porque probar ayuda a entender. (#GX2553)

Café con Testing. Martes de 12.15 a 12.45hs en el salón 25TG (Torres García). Estaremos participando junto a colegas del CES, GeneXus Consulting, Artech y K2B, conversando sobre distintas inquietudes del testing. Los invitamos a probar un café :) (#GX2551)

Automatizando Test, un año de experiencia con GXtest. Miércoles de 10.30 a 11hs. en el salón 2C (ballroom C). Por parte de Juan Martín y Federico, colegas de Concepto, escucharemos sus experiencias de uso de GXtest, luego de un año de trabajo en automatizar pruebas a sus sistemas. (#GX2424)

GXC Development Framework: Experiencias de testing y resultados obtenidos. Miércoles de 11 a 11.30hs. en el salón 2C (ballroom C). Matías Reina junto a Carolina Torrado de GeneXus Consulting, estarán hablando de testing de performance en proyectos de GeneXus Consulting, mostrando los resultados obtenidos. (#GX2457)

Roadmap de GXtest. Miércoles de 12.15 a 12.45hs. en el salón 2C (ballroom C). Fabián Baptista comentará sobre las últimas novedades y lo que se viene en GXtest. Hay mucho para contar! (#GX2491)

Relacionado con testing también recomiendo:

Todo sobre testing y más, en una Carrera, para conocer más sobre la carrera de testing del CES. (#GX2425)
Probar GeneXus code con GeneXus code, para conocer sobre los avances de GXunit este año, donde se podrán ver los resultados de un proyecto de grado de Facultad de Ingeniería tutoreado en conjunto por Abstracta y el CES. (#GX2417)
GXC Development Framework: Test de Aceptación, Do It! Guillermo de GeneXus Consulting estará contando la claves para hacer pruebas de aceptación exitosas. (#GX2412)

Para mi imperdibles todas! pero esta vez será la primera que lo miraré por Internet, una pena no estar por ahí para compartir todo esto.

Beneficios del testing automatizado, ¿realidad o ficción?

2011-09-09T04:46:00.000-07:00

Este es el título que le dimos a la charla dada en el pasado TechDay, el cual está basado en un paper de Paul Grossman, publicado por un importante proveedor de la industria del SW y HW. En este post haremos un resumen del contenido de la charla, ya que realmente nos parece importante mostrar los verdaderos beneficios en términos financieros, más que nada para dar más argumentos a alguien que quiere visualizar, o mostrar el valor que tiene este tipo de inversiones (ya que verán al final que no se trata de un gasto, sino en una inversión para ganar no sólo en calidad sino en ahorro de dinero).

¿Costo o inversión? Generalmente se dice que el testing automatizado permite ampliar el cumbrimiento y alcance de las pruebas, reducir costos, poner el foco de las pruebas manuales en lo que realmente interesa, encontrar defectos más temprano, etc., etc., etc., y de esa forma reducir costos y riesgo. Todo esto parece ser siempre la misma basura que plantean los vendedores de herramientas, sin justificación suficiente.

En cierta forma lo pondremos en duda.

El problema es que cuando se quiere "invertir" se analiza generalmente cuánto dinero me voy a ahorrar con cada peso que invierto en esto, para saber si es un costo que tiene la calidad, o una inversión que me ahorrará otros costos asociados a la falta de calidad, que es lo que siempre se dice. Es por esto que tenemos que mostrar estas cosas en números.
En esta charla intentamos analizar un poco más este tipo de planteos que se hacen siempre, como para que tengan criterios mejor fundamentados cuando quieran analizar si automatizar las pruebas funcionales.

Para probar funcionalmente un sistema se ejecutan pruebas diseñadas para ejercitar las funcionalidades probadas. Una vez que las pruebas ejecutan correctamente hay que volver a ejecutar los conjuntos de pruebas cada vez que hay cambios en el sistema, ante cada nueva liberación de una versión. Esto es lo que se conoce como test de regresión. En algunos casos además las mismas pruebas deben ser ejecutadas en distintos ambientes, considerando sistemas operativos, bases de datos, integración con distintos componentes, distintos navegadores, etc. No necesitamos mucho para darnos cuenta de los beneficios prácticos si logramos que esto sea ejecutado por una máquina.

Se requiere cierto esfuerzo para automatizar las pruebas y mantenerlas. Casi todas las herramientas de automatización brindan la posibilidad de "grabar" las pruebas y luego poder ejecutarlas, lo que se conoce como enfoque de record and playback. Esto generalmente sirve para pruebas simples y para aprender a usar la herramienta, pero cuando se quieren hacer pruebas más complejas generalmente es necesario conocer un poco más a fondo la forma en que trabaja la herramienta, manejar juegos de datos de pruebas, administrar los ambientes de prueba, las bases de datos de pruebas, etc. Una vez que tenemos solucionado esto, podemos ejecutar las pruebas tantas veces como queramos con muy poco esfuerzo.

Las mejores aplicaciones para aplicar testing automatizado son entonces las que tienen mucha repetitividad, y las que será necesario ejecutar muchas veces las pruebas (ya sea porque es un producto que tendrá muchas versiones, que se continúe con el mantenimiento haciendo fixes y parches, o porque se debe probar en distintas plataformas).

Si se automatizan las pruebas de un ciclo de desarrollo, para el siguiente ciclo las pruebas automatizadas podrán retestear lo que ya se automatizó con bajo esfuerzo, permitiendo que el equipo de pruebas aumente el tamaño del conjunto de pruebas, aumentando el cubrimiento. Si no fuera así, terminaríamos teniendo ciclos de pruebas más grandes que los ciclos de desarrollo (y cada vez más grandes) u optaríamos por dejar cosas sin probar, con los riesgos que eso implica. Esto es lo que una vez supimos llamarle el problema de la acumulatividad nula extrovertida sistematica (esto fue en la charla del Encuentro Genexus del 2010).

No todo se debe automatizar, y no hay que intentar remplazar el test manual por el automático, pues hay cosas que no se pueden automatizar (más que nada si necesitan verificación visual y determinación por parte del usuario), y en ocasiones es más fácil ejecutar algo manualmente que en forma automática.

¿Qué tanto automatizar? En cada caso será diferente, pero el paper dice que es bueno intentar comenzar con un objetivo del 10 o 15% de las pruebas de regresión, y a medida se va avanzando se podría llegar hasta un 60% aproximadamente.

Tampoco es la idea reducir el personal dedicado a testing. Pues el test manual aún se necesita, y las pruebas automatizadas requieren cierto mantenimiento, además de las que se sigan automatizando. Entonces, ¿dónde están los beneficios financieros? Lo más importante es que al automatizar podemos expandir dramáticamente el alcance de las pruebas con el mismo costo (con la misma inversión), y eso es algo que financieramente da ventajas claras: conservar los costos y aumentar el beneficio.

Veamos con un ejemplo hipotético que sea más entendible por alguien que decide sobre las finanzas de una empresa:

Un tester manual ejecuta pruebas 8 horas por día, y se va a su casa. En ese momento el testing se detiene. Con el test automatizado se puede estar ejecutando pruebas 16 horas más por día (en el mejor caso claro...), bajo el mismo costo, lo cual reduce el costo de las horas de test. El paper plantea que un tester en promedio cuesta 50u$s la hora (ojalá en Uruguay fuera igual!) y si es senior cuesta 75u$s (divino!). Siendo así serían 400u$s o 600u$s respectivamente por día, pero en el segundo caso serían 16 horas más que en el primero (esto es porque considera que el senior es el que sabe automatizar, el otro sólo se considera para test manual). Además los test automatizados corren más rápido que los test manuales, en promedio digamos que 5 veces más rápido (generalmente es más, pero no exageremos). Si hablamos de un equipo de 10 personas, 5 senior y 5 para test manual, tenemos un costo mensual de 105.000u$s (168hs por mes, o sea 8 horas por 21 días, 42.000 en test manual y 63.000 de testers senior). Esto en principio nos da un total de 1.350 horas a un costo de 78u$s la hora (acá se está considerando que de las 168 horas mensuales de trabajo, se estará ejecutando 135, lo cual podría suponerse como razonable si se considera cualquier overhead como enfermedad, vacaciones, capacitación, etc.). Si ponemos a 3 de los senior a automatizar, el costo seguirá siendo el mismo pero tendríamos 16hs x 3 ing x 21 días x 5 veces más test por hora, lo que nos da un agregado de 5.040 horas mensuales equivalentes a horas de test manual. Si consideramos el resto del equipo haciendo pruebas manuales (7 x 135) son 945 horas más, lo que da en total 5.985hs de test con un costo de 17,5u$s la hora (105.000u$s / 5.985 horas). Esto es un beneficio expresado en términos financieros, que se entiende fácilmente. Pasamos de pagar la hora de test de 78u$s a 17,5u$s, o visto de otro modo, aumentamos las horas de prueba de 1.350 a 5.985 bajo el mismo costo.

Ahora, esto nos muestra claramente que hay mejoras en cuanto a las horas de ejecución de pruebas, pero seguramente nos agregue más costo pues encontraremos más errores!!!! ¿Queremos eso?? Claro que SÍ, y veremos ahora cómo encontrar más errores nos ahorra costos a pesar que nos da más trabajo (es algo obvio, pero hagamos más cuentas para visualizarlo mejor).

Es conocida en ingeniería de software la gráfica que muestra el costo de corregir un defecto detectado según en la etapa que se haya encontrado (desarrollo, integración, beta testing, producción). Se muestra un estudio de cuántas horas en promedio cuesta corregir un defecto según la etapa, y considerando costo por hora, cuánto cuesta en dólares. Esto no está considerando siquiera los costos ocultos que hay como la pérdida de imagen, confianza, e incluso el desgaste del equipo.

Esta tabla está hecha en base a un estudio hecho con empresas de desarrollo de software de intercambio financiero electrónico (Planning Report 02-3, "The Economic Impacts of Inadequate Infrastructure for Software Testing," Prepared by RTI for National Institute of Standards and Technology, May 2002, p 7-12.). Muestra el costo en horas de reparar un bug según la fase en la que se encuentra. Luego se aplicó como para visualizar en dinero un costo por hora de 75u$s.

Lo que se ve claramente de esto es algo ya muy conocido, que es que cuanto antes se encuentren los bugs mejor! Y como vamos a tener testers que trabajan 24hs al día, ejecutando más rápido, es más probable que se encuentren más errores antes de pasar las versiones a betatesting o a producción. Es difícil estimar cuántos, pero por cada bug que se encuentre más temprano se ganará al menos 200u$s…. nada mal!!! Esto lo pueden ajustar al precio que les cuesta la hora de sus desarrolladores, y seguirá valiendo la pena.

En estos números se llega a la conclusión de cuánto cuesta un defecto encontrado en cada una de las distintas etapas.

Pregunta al margen: ¿están llevando registro de qué incidentes, y qué complejidad y prioridad cada uno, encuentran en cada fase? Si aún no lo están haciendo, les aconsejo que comiencen a utilizar algún sistema de gestión de incidentes como Mantis Bug Tracker o cualquiera similar, que son gratuitos, muy buenos, y dan la posibilidad de tener esta información en todo momento y hacer un correcto seguimiento de cada asunto.

También se plantea que la automatización permite encontrar errores que no serían fáciles de encontrar manualmente. Por ejemplo errores de memoria que se dan luego de ejecutar muchas veces una funcionalidad, y ni que hablar si nos referimos a pruebas de concurrencia o performance.
Hay muchas cosas que sólo un tester manual puede ver, y otras que tal vez es más probable que las vea una prueba automatizada. Por ejemplo si queremos verificar que cada elemento pedido retorne un código de respuesta sin error (en el caso de http sería que no devuelva ningún 404 o 500 por ejemplo), o si queremos ver que todas las URL están configuradas con https, eso se puede programar y automatizar para que en todas las pruebas se verifique, y en cambio un tester manual tal vez no le presta atención en cada ocasión, dejando pasar por alto en alguna oportunidad por algún despiste.

A modo de resumen podemos decir que hay dos cosas a las que da valor el test automatizado:

Business value
IT value

Da valor al negocio mejorando la calidad, evitando problemas de operativa, pérdida de imagen de clientes, e incluso evitando problemas legales, y mejora el trabajo del grupo de IT ya que le simplifica las tareas rutinarias, permitiendo que con el mismo costo hagan mucho más y mejor.

TechDay 2

2011-08-23T06:43:00.000-07:00

Este año tenemos la oportunidad de participar del TechDay que se realizará en Zona América el 30 y 31 de agosto. Esperemos puedan acompañarnos.

http://www.zonamerica.com/techday

Estaremos dando una charla mostrando los beneficios financieros que se pueden obtener con la automatización de pruebas, intentando desmitificar el tema.

Efficient Regression Tests for Database Applications

2011-07-28T06:19:00.000-07:00

Desde el abstract de este trabajo se plantea algo que es muy cierto, no hay casi investigación en cuanto a pruebas de regresión en sistemas que utilicen bases de datos, el cual plantea problemáticas particulares, para nada triviales.

En este caso el paper aborda un problema que hemos tenido que enfrentar varias veces, y sobre el cual nos han preguntado más de una vez: ¿cómo manejar los casos de prueba y la base de datos?

Para explicar un poco mejor la problemática: siempre se dice que los test deben ser independientes, y deberían ser diseñados de forma tal que puedan correr en cualquier orden. Esto es válido para aplicaciones state-less, pero en el caso de aplicaciones con bases de datos, esto no es nada fácil, generalmente al ejecutar un caso de prueba se modifica el estado de la base de datos, perturbando el estado inicial sobre el que trabajarán el resto de los casos de prueba que ejecutarán luego.

Primero veamos unas definiciones, y luego discutamos la propuesta que plantea.

Test Database (D): usan esta nomenclatura para referirse al estado de la aplicación antes de comenzar el caso de prueba.

Reset (R): operación que nos permite recuperar el estado inicial de la base de datos, lo cual sería hacer un restore de un backup previo. Esto es necesario para poder ejecutar los tests desde un mismo estado inicial, y por eso la necesidad de hacer un backup de un estado inicial conocido. Un problema con esto es que es una operación de cómputo muy costosa (del orden de minutos a horas, de acuerdo al tamaño de la base de datos).

Test Run (T): ejecución de un test.

False Negative: un test run que a pesar de que el sistema bajo pruebas ejecuta correctamente, el test nos dice que hay un error. Esto agrega mucho costo pues el tester ante el resultado buscará (sin sentido) dónde está el bug.

False Positive: un test run que no muestra un fallo a pesar de que la aplicación tiene un bug. Tanto esto como el falso negativo pueden darse por un estado inicial incorrecto de la base de datos.

Entonces, el problema es poder programar los Test Runs y los Resets de forma eficiente y minimizando los falsos positivos y negativos.

Se plantean distintas estrategias, y comienza explicando la más básica, que consiste en reiniciar el estado de la base luego de ejecutar cada test, como para que el estado inicial de los test sea siempre igual.

R.T1.R.T2.R.T3........R.Tn

Obviamente, esta es la opción más costosa. De aquí que se plantea analizar qué casos de prueba afectan el resultado de otros, y de esa forma ir modificando el orden de ejecución y minimizar la cantidad de Reset que se apliquen. Para esto es que construyeron un prototipo de una herramienta, que les permitió decidir qué algoritmo era el más apropiado para su objetivo.

Nosotros a esto también le hemos encontrado otras dos soluciones.

Debido al conocimiento del tester sobre el negocio de la aplicación, podemos implementar una estrategia similar a uno de los métodos que plantean los autores (pero manual). La misma implica agrupar los tests en suites en los que estén ordenados adecuadamente.

Seguramente si un test falla, hará que fallen el resto pues estos tienen como precondición que los test cases previos hayan ejecutado correctamente. Esto tiene como ventaja la posibilidad de probar ciclos funcionales completos, pero como contrapartida, si un test falla, entonces falla toda la suite, y de esa forma quedarán algunas funcionalidades sin probar hasta que no se solucionen los problemas de los tests anteriores.

Esto también puede ser visto como una ventaja, ya que se está notificando de que no se va a poder ejecutar esa funcionalidad, pues una funcionalidad previa no está funcionando. Lo que hay que intentar tener cuidado en este caso, es de hacer que una suite no afecte a otras, o sea, que trabajen sobre distintos juegos de datos.

Otra opción es minimizar el costo de las operaciones de Reset. En lugar de utilizar un restore de un backup se podrían tener operaciones, o procedimientos, sqls, etc, que sean capaces de borrar el contenido de una tabla, o de volver a copiar el contenido inicial, etc. Incluso podría ser un caso de prueba automatizado que borre instancias de una entidad luego que el caso de prueba previo las crea.

¿Alguna vez se enfrentaron a un problema similar?

¿Cómo han intentado resolverlo?

¿La calidad está siendo un problema?

2011-07-14T08:54:00.000-07:00

Leyendo un paper llamado "Surviving the Top 10 Challenges of Software Test Automation" de Randall W. Rice, me encontré una frase que me gustó la cual dice

The cost of a single defect in most organizations can offset the price of one or more tool licenses.

O sea, que el costo de un defecto en la mayoría de las organizaciones compensa el costo de una o más licencias de herramientas. Esto a modo de dar hincapié en la importancia de automatizar las pruebas, el por qué valen la pena, aunque creo que está basado en una creencia y no en un estudio, pero también creo que tenga grandes chances de ser próximo a la realidad.

El artículo lo pueden leer aquí, pero más allá de los puntos específicos que trata, lo que me interesa es el enfoque de intentar analizar cuáles son las fallas que se pueden dar al intentar automatizar las pruebas de un sistema, y atacar cada una buscando cómo lograrlo. Me hizo acordar un poco a la charla que dimos en el pasado encuentro GeneXus. Destaco a continuación solo algunos puntos del artículo.

Entre otras cosas menciona cosas que siempre hemos dicho, tal como que automatizar algo que es caótico, sin organización suficiente, lo único que logra es hacer que ese caos sea más veloz (If you do not know which tests are the most important and which tests are the most applicable for automation, the tool will only help perform a bad test faster). Esto además lo muestra con un ejemplo muy práctico, sobre cómo construir bibliotecas de madera. Para esto una de las cosas a hacer es cortar madera, y como estaba cansado de hacerlo a mano (con una sierra de mano) y eso le lleva mucho tiempo, va con un vendedor y este le convence de comprar una sierra eléctrica. Ahora, sin conocimientos en carpintería lo único que logra con la sierra eléctrica es cometer errores más rápido!

Recomienda también tener un experto en "la herramienta" dentro de la empresa, donde "la herramienta" podría ser cualquiera de las que se esté utilizando para automatizar o dar soporte a cualquiera de las actividades de testing, que no tiene por qué ser una sola. Esto con el objetivo de tener un referente, alguien que administre la plataforma, y se encargue de hacer las cosas lo mejor posible, y transmitir al resto del equipo estas oportunidades de mejora.

Como conclusión del artículo destaco la necesidad de analizar si la falta de calidad en nuestras entregas, en nuestras liberaciones de nuestros desarrollos, está siendo un problema, algo que nos agrega costos (en ocasiones no hace falta analizar mucho, "salta a la vista"). En ese caso, ¿por qué no intentamos hacer algo para cambiarlo? Esto podría ser considerar herramientas, ya sea para automatizar la ejecución de pruebas, así como también para gestionar incidentes, gestionar requerimientos y sus pruebas (manuales o automatizadas), etc., aprendiendo como usarlas, e institucionalizando las buenas prácticas. Tal vez esto también se logre planificando mejor nuestros esfuerzos (no sólo con nuevas herramientas), pero seguro que este tipo de análisis, estas preguntas, las deberíamos hacer de vez en cuando.

Generación automática de datos de prueba

2011-06-06T05:11:00.000-07:00

Me vine hace 4 meses a España (a la UCLM en Ciudad Real) a hacer un doctorado en informática, especializándome en testing, con lo cual espero poder contribuir a las metas que tenemos.

En el primer año la idea es hacer los cursos de máster, y avanzar en lo que será la tesis doctoral. En este post les quiero compartir la idea inicial sobre la que voy a estar trabajando. Vale aclarar para comenzar que el objetivo principal era investigar en un tema que combine dos cosas muy importantes: que esté dentro del área de investigación del grupo al que me incorporé, y que sea algo que tenga aplicación real, práctica, que sea útil especialmente en mejorar la forma en que hacemos testing de aplicaciones en Uruguay, y si había chance de yapa, que el caso de estudio esté aplicado o vinculado de alguna forma a GeneXus, GXtest o GXunit.

Viéndolo en forma simplificada (o abstracta), los grandes rasgos a desarrollar (prototipando) de un sistema de información son:

la estructura de datos
las reglas de negocio (validaciones de datos, restricciones, etc.)
los procedimientos que procesan estos datos y las pantallas que los muestran

¿Cómo se prueba esto?

Se genera la aplicación, se instala (con los entornos modernos esto es apretar F5)
Se accede a la aplicación y se cargan datos para probar manualmente que lo que uno programó se esté verificando y funcionando (estructura y lógica)

Cargar estos datos manualmente puede ser bastante tedioso y error prone (como se suele decir para todas las tareas aburridas), y si las reglas implementadas son complejas o tienen muchas condiciones, seguramente no se consideren todos los casos importantes y queden así sin verificar. Lo mismo con los procedimientos, seguramente no se prueben con suficiente cobertura, verificando las distintas condiciones, y en ocasiones eso puede ser por el tiempo que llevaría cargar datos a mano para disparar las condiciones adecuadas para que se ejecute determinada regla. Incluso queda generalmente sin probar cosas tan simples como ver que el tipo de input utilizado en la pantalla sea el apropiado para el tipo de datos usado a nivel de la base de datos (si es un string que sea del largo apropiado, pues se pueden generar excepciones no controladas o pérdida de información en caso que se pueda ingresar un string más largo del que se puede almacenar).

Propuesta

Facilitar la generación de datos de prueba tomando información del modelo de desarrollo en tres niveles

Estructura de datos y pantallas
Reglas de negocio
Procedimientos

Los datos deben generarse para dos cosas, para poblar la base y para los datapools a utilizar en los test cases (ya sean a ejecutar automáticamente o en forma manual).

¿Cómo?

De las estructuras, con la metadata, generar valores límite para las clases de equivalencia que se puedan definir sobre los variables. Técnicas de combinación de valores. Todo automático a partir del modelo de desarrollo.
De las reglas, generar valores límite para las condiciones. Técnicas de combinación de valores. Todo automático a partir del modelo de desarrollo.
De los procedimientos, aplicar técnicas de caja blanca, modelar manualmente o generar automáticamente máquinas de estado que representen la lógica, aplicar técnicas de MBT (model-based testing). Técnicas de combinación de valores a partir de operaciones entre valores. Todo automático a partir del modelo de desarrollo, opcionalmente agregar modelos específicos para la prueba.

Ejemplos:

Estructura de datos: Si definimos un atributo tipo string de largo 10, en el datapool voy a poner valores de largo nulo, largo 9, 10, 11, 200, para ver qué pasa en el alta o modificación del dato que estoy verificando.
Reglas de negocio: Si indico que un número no puede ser menor que cero, entonces probaré con valores positivos, negativos, con el 0, etc. De esta forma verificar que las reglas se están verificando tal como es deseable.
Procedimientos : Si el código de un procedimiento realiza una evaluación de una variable, yendo por un flujo si es positiva y por otro si es menor o igual a 0, entonces se podrían definir valores de prueba que hagan que esas condiciones sean evaluadas a true y a false, incluso considerando los valores límites que siempre son situaciones típicas de error. Considerando otras situaciones típicas de error se podrían generar pruebas para para evitarlas. Por ejemplo, si dos valores aparecen sumados y asignados a otra variable, sería interesante considerar una prueba donde esos valores sean los máximos soportados por el tipo de datos, como para ver si no se produce un overflow o algo similar.

El objetivo más interesante a cumplir es que uno si programa algo (independiente de que sea en GeneXus) define estructuras de datos y procedimientos sobre esto. Entonces para probar una funcionalidad tiene que generar datos de prueba en forma manual, con código o por la interfaz de la aplicación, e incluso hay que pensar en las distintas situaciones que se intentan contemplar y ver de que al ejecutar se cumple lo que uno quería hacer. Lo que se facilita con esto es que al programar y armar las estructuras de datos, se llenarían datos automáticamente que te permiten probar fácilmente los casos interesantes en base a lo que programaste, en base a las estructuras, a las reglas de negocio, y en base a los procedimientos.

En el caso de GeneXus, podría pensarse no sólo en generar datos sino generar pruebas automáticas que usen estos datos, visto que ya logramos con GXtest Generator generar pruebas automáticamente a partir de la información disponible en la KB (actualmente para GXtest, a futuro tal vez también para GXunit). En principio con probar el CRUD de las entidades ya es algo que agrega valor. Luego (nivel tres) probar los procedimientos. No se si esto se puede extender fácilmente para probar un ciclo funcional completo, pero ya se verá al ir avanzando.

Cualquier aporte o sugerencia será bienvenida, pues como dije al comienzo, el objetivo de esto es sacar algo que nos sirva.

Testing Day 2011

2011-05-25T02:10:00.001-07:00

Ayer jueves 26 de mayo de 2011 se celebró en el KDC del LATU el Testing Day 2011.
Estamos muy contentos de haber participado y compartido con la comunidad de testing de Uruguay.

Más info en el grupo Linked-in de Centro de Excelencia en Testing.

Yo acá a la distancia me quedé con ganas de asistir, espero que por ahí lo hayan podido aprovechar! Es una alegría ver lo que fue la Agenda del Evento ya que estuvo llena de excelentes propuestas, todas alrededor de este tema que a nosotros tanto nos apasiona. Me interesaron muchas las charlas, en particular las del CES y el anuncio sobre la carrera de testing. La mesa redonda me dijeron que estuvo muy buena. Otra charla que me resultó muy interesante fue la que planteó Pragma, sobre la cual leí hace poco en la revista InfoTesting que aprovecho a compartir. Es una iniciativa argentina donde se pretende difundir material de testing en castellano.

Cómo crece la comunidad de testing!

BrokenTest pattern para refrescar la memoria

2011-05-05T05:50:00.000-07:00

Dicen que si estamos trabajando en automatizar pruebas, una buena práctica para volver el día de mañana y recordar más fácil en qué habíamos quedado, es dejar un test que falle. Esto nos hará pensar el por qué falla, qué estaba intentando probar, y así recordar el resto.

Puede ser útil incluso para el programador el dejar en su máquina código que no compila, e incluso para cuando se va a almorzar.

http://c2.com/cgi/wiki?BrokenTest

Knowledge Management en Testing (parte 4)

2011-03-25T06:36:00.000-07:00

Como para terminar con esta serie me queda comentarles sobre una metodología desarrollada en un doctorado acá en la UCLM para mejorar la gestión del conocimiento de una empresa. Se las cuento en forma resumida, pero ya adaptada a lo que sería lo que nos interesa transmitirles, enfocada a testing y a GeneXus.

Lo primero consistía en identificar las fuentes de conocimiento disponibles y categorizarlas:

Documentación

De sistema, técnica, especificaciones
Casos de prueba
Metodologías

Sistema o producto

Código fuente / KB
Base de datos (incluyendo datos de producción, o datos de prueba)
El sistema ejecutando

Personas

Desarrolladores
Testers
Clientes

Herramientas de apoyo

Wikis
Issue trackers
las que mencionamos en el post anterior

Luego pasaríamos a identificar cuáles son los flujos de conocimiento que se dan en la organización, de qué manera las fuentes interactúan en los distintos procesos y actividades. Incluso plantean una forma de extender el modelado de procesos (con SPEM) como para poder representar esto.

Una vez que tenemos claro el esquema la idea es identificar fallos en el flujo de conocimiento, y para esto presentan una checklist de situaciones a revisar para evitar

Hubs: punto que llegan muchos flujos (congestión, cuello de botella)
Black holes: proceso que no origina flujos (nunca es consultado)
Springs: se originan flujos pero no entra ninguno (el problema es que no recibe feedback)
Missing links: no hay flujo, o no funciona correctamente

Este es un resumen muuuy breve de todo lo que plantea la metodología, pero creo que al menos estos puntos que puse aquí pueden ser puestos en la práctica a bajo costo, y pueden hacernos mejorar la forma en la que gestionamos lo más importante que tenemos, el conocimiento de nuestra empresa.

Knowledge Management en Testing (parte 3)

2011-03-25T06:34:00.000-07:00

Hay varias herramientas (gratuitas y pagas) para ayudarnos con la gestión del conocimiento, específicamente en lo que refiere a testing. En este post quiero compartir algunas que me resultaron interesantes, y espero les puedan ser útiles:

CMap Tools para mapas conceptuales, dibujar modelos que nos puedan servir para expresar ideas.
Mantis Bug Tracker para gestionar incidentes
Sharepoint (de Microsoft), Mindtouch o Alfresco (opción open) para gestión de documentos, wikis, portal corporativo, etc.
Mediawiki / GXwiki - para generar documentación fácil de acceder, mantener y versionar.
GXtest para gestionar las pruebas y sus resultados.
Google Desktop - Buscar contenido dentro de un PC. De aquí surge una duda ¿Cómo resolver encontrar contenido cuando los archivos estan distrbuídos en las distintas máquinas? ¿existirán herramientas del estilo Google Desktop para máquinas remotas que quieran compartir sus documentos? Sería como una herramienta P2P pero capaz de leer e indexar el contenido de los archivos y no sólo los nombres.
Hay herramientas que si se las "engancha" al servidor de mails, son capaces de identificar expertos. O sea, leen el mail, y van asociando conceptos a los usuarios, de acuerdo a qué tanto hablan de ello. Por ejemplo, si se repite mucho "data provider", en cadenas de conversación con una persona, entonces es posible realizar la búsqueda de expertos en el tema "data provider" y aparecerá esta persona. Incluso podrían vincularse temas relacionados a partir del análisis que estas herramientas logran hacer sobre los emails. Me resulta un poco delicado el brindar acceso para análisis sobre el email de los empleados, pues da lugar a que luego el jefe se le ocurra buscar al experto de "sábado a la noche" o "fútbol" y vea la cantidad de emails que nombran este tema :)
EPF Composer - para documentar procesos siguiendo el estándar SPEM y publicándolo en una web, fácil de compartir y mantener, pudiendo así captar y difundir las metodologías y procesos utilizados en la organización. El escenario ideal en este tipo de cosas es que luego haya una herramienta capaz de tomar la especificación del proceso como para "ejecutarla". O sea, que administre el workflow de trabajo, gestione las entradas y salidas, notifique a los usuarios, etc. En este sentido (pero bajo un proceso definido) se está trabajando con XPM, el cual apoya la gestión del conocimiento del desarrollo con GeneXus, y a futuro gestionará incluso la de las pruebas en forma integrada con GXtest.

En este enlace http://sites.google.com/site/toolsgsd/ hay un listado de herramientas (hecho en el Grupo Alarcos, de la UCLM) para el desarrollo global, y entre tantas se listan herramientas que apoyan la gestión de conocimiento en distintas áreas.

En el próximo y último artículo les contaré de una metodología desarrollada en un proyecto de doctorado para detectar problemas y mejorar la gestión del conocimiento en una empresa.

Knowledge Management en Testing (parte 2)

2011-03-24T15:17:00.000-07:00

Continuando con la línea del post anterior, queríamos compartir algunas ideas más sobre KM (gestión del conocimiento), específicamente aplicado al área de las pruebas de software. En particular, algunas técnicas para mejorar los distintos pasos de la gestión del conocimiento (recordar que eran creación, captura, organización, acceso y uso):

CREACIÓN

Lluvia de ideas (Brainstorming): ¿Cómo probamos una determinada funcionalidad? ¿cómo organizamos las pruebas? Hay muchas cuestiones, muchos nuevos desafíos que tal vez pueda "generar conocimiento" a partir de reuniones de equipo en donde se expongan todas las ideas que surjan en una lluvia de ideas (o tormenta de ideas como estamos acostumbrados a llamarle nosotros).

Comunidades de práctica: expertos en un área (tecnología, negocio, etc.) exponiendo información sobre determinado tema, lo cual podría ser sobre el dominio de la aplicación bajo pruebas, técnicas de diseño, herramientas de apoyo, etc.

CAPTURA / ORGANIZACIÓN / ACCESO

Mapas conceptuales: fáciles de hacer, permiten compartir y entender ideas en forma muy fácil (usando por ejemplo CMaps Tools).

Mini artículos: contando experiencias, problemas resueltos (se puede llevar a cabo en una wiki o foro por ejemplo).

Repositorio de conocimiento: archivos y cualquier tipo de material, ordenado y categorizado.

Foros de discusión internos: a modo de poder consultar luego lo discutido, y que no quede en chats o emails que no son accesibles por el resto de la organización.

Páginas amarillas: la idea es documentar quién sabe de qué cosa. Esto tal vez aplique más que nada a organizaciones muy grandes, en las PyMEs digamos que nos conocemos todos.

Issue tracker: esto es de los puntos más importantes a gestionar con respecto a las pruebas. Saber qué problemas hay detectados, resueltos, resueltos cuándo y por quién, etc. Si puede estar integrado con el SVN y otras herramientas que manejan información sobre el código, y más cosas, mucho mejor.

¿Conocen o usan alguna herramienta para ayudar en estas tareas?

Foto: Frosted Fantasies

Leer más: Knowledge Management en Testing (parte 3)

Knowledge Management en el Testing (parte 1)

2011-03-21T07:31:00.000-07:00

Algo que no puedo evitar al estar estudiando cualquier tema, es vincularlo inmediatamente con el mundo GeneXus, y obviamente todo lo posible con GXtest, con la forma en la que trabajamos nosotros o nuestros colegas. En este post en particular les quiero dejar algunos apuntes de un tema muy interesante que es el de gestión del conocimiento, pero en particular aplicado al entorno del testing, y en algunas cosas en particular a las empresas que trabajan con GeneXus.

De las definiciones dadas las que más me gustó fue: Conjunto de estrategias y procesos para identificar, capturar y aprovechar el conocimiento para ayudar a la corporación a ser más competitiva (American Productivity and Quality Center).

Se pueden distinguir dos "tipos" de conocimiento:

Conocimiento tácito: todo conocimiento que está en las personas
Conocimiento explícito: conocimiento que está expresado en documentos, código, etc.

Ahora, ¿por qué es importante gestionar el conocimiento?

Rotación del personal (pérdida de expertos). Esto es algo que se da cada vez más en la industria del software.
Cambios de tecnologías. Por más que con GeneXus esto se reduce muchísimo, tenemos que estar atentos a las nuevas tendencias y entender cómo funcionan y cómo funcionar con ellas.
Necesidades de contacto más estrechas con los clientes.
Necesidad de reducir tiempos de respuesta. Es inaceptable que por falta de información, o por una mala gestión de la misma nuestros tiempos de reacción sean malos.

Entonces concluimos que esto nos ayuda a:

Mejorar calidad
Minimizar costos

La Gestión del conocimiento sigue los siguientes pasos:

Creación
Captura
Organización
Acceso
Uso

Es necesario "aceitar" cada uno de ellos para que todo funcione correctamente. Es necesario compartir el conocimiento, hacer que fluya. Generar conocimiento, tanto explícito como tácito (o sea, no es suficiente con documentar cosas, sino también que hay que hacer que el personal adquiera conocimiento, tanto de fuentes internas como externas).

Tengo más apuntes para compartir pero no quería agobiar con todo junto, por lo que por ahora con esto les dejamos la pregunta: ¿Gestionan el conocimiento generado en el testing? ¿Cómo?

Leer más: Knowledge Management en Testing (parte 2)

Encuentro GeneXus España 2011

2011-02-16T01:05:00.000-08:00

Aprovechando que estoy por España, vamos a tener participación en el Encuentro a celebrarse el 15 de marzo, en Logroño (La Rioja, España), impartiendo un taller de GXtest, donde mostraremos el producto funcionando.

Pueden ver información del encuentro por aquí.

Como es de esperar en todo encuentro GeneXus, se abordarán los temas de punta en tecnologías, así como también las últimas novedades de GeneXus, y temas no tan técnicos de interés, teniendo la oportunidad de compartir experiencias con la comunidad que viene creciendo como en todos lados.

GXtest Generator: Generador automático de casos de prueba ....

2011-02-11T08:12:00.000-08:00

¿Qué tal si a partir de una transacción se generan casos de prueba automáticamente? ¿Qué tal si estos casos de prueba se pueden ejecutar automáticamente con GXtest, o desde el propio IDE de GeneXus?

Hace un tiempo decidimos dejar abierta la posibilidad para que se pueda con herramientas externas generar casos de prueba que luego puedan ser visualizados, modificados y ejecutados desde GXtest.

Por junio del 2009 planteamos algunos post sobre interoperabilidad con GXtest y por abril del 2010 estuvimos conversando en el GUG sobre como se podría utilizar la información de la KB para generar casos de prueba.

Hace unos meses desde GeneXus Japón, tras comenzar a utilizar GXtest decidieron apostar a la generación automática de casos de prueba para mejorar la productividad en testing y ayudar en la calidad de sus aplicaciones. En esta tarea se embarcó Luciano y Yokoi, que desarrollaron una herramienta muy interesante que creemos va a marcar un hito muy importante en el testing de aplicaciones GeneXus, esta herramienta la denominaron GXtest Generator.

GXtest Generator permite crear casos de prueba a partir de una transacción y si dicha transacción tiene el WorkWith aplicado entonces también genera casos que utilizan los distintos objetos creados en dicho pattern. Estos casos de prueba no solo realizan las acciones más comunes sobre la transacción y sobre los objetos generados, sino que también se pueden alimentar con datos que ingrese el usuario para poder crear una variedad importante de casos de prueba. A su vez, estos casos de prueba son una unidad fundamental para componer luego nuevos casos de prueba más complejos.

Para explicarles mejor como funciona, Luciano hizo un video sencillo que lo muestra en acción. También pueden encontrar la documentación en la wiki de Abstracta.

Este año queremos potenciar el trabajo que han hecho en Japón. Queremos que se puedan ejecutar estos casos de prueba generados directamente en el IDE de GeneXus y que se puedan ver los resultados ahí mismo. El objetivo es sacarle más jugo de manera más rápida. Imaginen que tengan la opción de apretar F5, se genere la aplicación, se generen las pruebas, y al abrir el Browser con la aplicación se comiencen a ejecutar las pruebas generadas automáticamente.

También queremos agregarle más cosas como generar datos en base al tipo de dato, permitir customizar más los casos de prueba generados, etc.

Una de las cosas más importantes de GXtest Generator es que sus creadores han decidido dejarla libre para la comunidad, por lo tanto todo aquel que quiera jugar o extenderlo puede bajar los fuentes desde assembla, o el pattern pronto para utilizar desde GeneXus Marketplace.

Para ejecutar los casos de prueba se pueden bajar una versión trial de GXtest.

Queremos agradecer a todo GeneXus Japón, y en especial a Luciano y Yokoi.

Creemos que esta herramienta es útil en varios contextos y que va a ser la primera de varias herramientas que generen casos de prueba volviendo el testing en aplicaciones GeneXus cada vez más productivo, siendo este también un diferencial importante para quienes trabajen en esta plataforma.

Buenas prácticas de automatización con GXtest

2011-02-01T04:14:00.001-08:00

Hace poco terminamos un proyecto inicial (unas 70 pruebas) de automatización de pruebas de XPM.
XPM es un herramienta muy completa para gerenciamiento de proyectos y trabajo en equipo.
El proyecto fue exitoso ya que logramos cumplir con todos los objetivos planteados inicialmente.

Durante el transcurso del mismo utilizamos varias prácticas que, si bien las hemos mencionado y las recomendamos a nuestros clientes, nunca las habíamos integrado en un artículo de buenas prácticas. Son temas sencillos pero que a la larga o a la corta hacen una gran diferencia.

Nomenclatura
Es importante definir una nomenclatura de casos de prueba y carpetas. Esta práctica si bien es simple redunda en muchos beneficios. Una recomendación para los nombres de los casos de prueba es distinguir aquellos que son pensados como componentes de otros casos de prueba de que son pensados como ciclos que incluyen los componentes. A los casos de prueba integradores (ciclos) se los puede nombrar con Ciclo
Por otro lado es útil definir una estructura de carpetas que permita separar los casos de prueba generales (típicamente login, acceso a los menúes, etc) de los casos de prueba de los distintos módulos.
Muchas veces también surgen casos de prueba temporales a los mismos se los puede nombrar con un prefijo común como pru o tmp.

Comentarios y Descripciones
Cada caso de prueba y datapool puede tener una descripción que diga en líneas generales cuál es su objetivo. Por otro lado dentro de los casos de pruebas podemos incluir comentarios que ilustren los distintos pasos dentro del caso de prueba. Dentro de los datapool es conveniente agregar una columna más que sea comentarios en la cual en caso de que se quiera se agregue un comentario para cada dato que se utilizará en las pruebas.

Componentes Reutilizables
Una de las ventajas principales de GXtest es la facilidad para reutilizar casos de prueba. Para poder explotar al máximo esta cualidad es importante definir cuáles son los casos de prueba que serán reutilizados, que variables de entrada y salida tendrán y que datapools utilizarán. Luego se construyen los casos de prueba principales simplemente anidando otros casos de prueba.

Descripción de las validaciones
Cada validación en GXtest tiene un campo extra en el cual se le puede incluir una descripción a ser mostrada en caso de que falle. Esta descripción es sumamente útil a la hora de analizar los resultados de una ejecución.

¿Que otras buenas prácticas utilizan ustedes con GXtest?

Upgrade de GXtest liberado (v. 1.1.4)

2011-01-21T04:58:00.000-08:00

Desde la liberación de la versión 1.1 hemos continuado desarrollando y mejorando el producto. Hace muy pocos días dejamos disponible una nueva versión (v. 1.1.4) y no queríamos dejar de hacer mención de los principales avances que tiene, más allá de las mejoras y bugfixes:

Simplificación del modelo

Simplificación en el uso de datapools relacionados, ya no se necesita el datapool datasets para relacionar datos de distintos datapools. Por otro lado se brinda la posibilidad de relacionar datos con distintos niveles de anidación.
No es necesario usar el dummy event, se permiten aristas sin eventos. Al ver que esto era algo común, optamos por no requerir agregar un evento en cada arista.

Mejor interpretación de resultados

Se mejora la visualización de resultados en el Designer, sin abrir las responses obtenidas en otro tab, sino en un cuadro abajo, en forma mucho más práctica (ver ejemplo).
Se renderizan los css y las imágenes en las html guardadas como responses de las ejecuciones (eso se puede ver en el ejemplo anterior).

Generación de casos de prueba

Hace mucho tiempo comentamos que dejamos disponible una interfaz por la cual se podrían generar casos de prueba en forma externa, tal que se puedan cargar luego en GXtest y ejecutarlos desde ahí. Esto permite que por ejemplo, a partir de la KB, o de una recorrida por la aplicación o modelos de alto nivel, se generen casos de prueba que luego se puedan usar en GXtest. En esta nueva versión se incluyeron mejoras en esta interfaz, permitiendo expresar muchas más cosas en forma más simple y funcional.
Con este fin también se facilitó el formato con el que se exportan e importan los datapools (csv en lugar de xml).

Facilidad de instalación

Para brindarle la metadata de la KB a GXtest es necesario instalar una extension (en el caso de que se esté trabajando con GX X o superior). Ahora esta extension está en el GeneXus Marketplace, lo cual hace más fácil su instalación.

Esperamos que puedan probarlas y darnos su opinión. Desde ya gracias!

¿Está creciendo la comunidad de testing en Uruguay?

2010-12-23T16:00:00.000-08:00

Los interesados en testing que nos leen, dónde se informan? qué foros siguen? dónde intentan actualizarse sobre lo que pasa en esta área del conocimiento de la informática?

En el último tiempo hemos tenido varias propuestas nuevas para compartir y obtener información, consultas, etc.:

Centro de Excelencia en Testing: este grupo fue creado por Ignacio Larrañaga de TCS y creo que es donde más gente de testing de Uruguay en particular partcipa. Está muy bueno para mantenerse informado de eventos locales, etc.
Página del Centro de Ensayos de Software: siempre publican información sobre actividades, cursos y eventos que organizan o en los que participan.
Blog del Centro de Ensayos de Software: hoy se inauguró el blog del CES. Seguramente podremos encontrar otro espacio compartido para mantenernos al tanto de todo a lo que testing se refiere.
Blog de GXunit: el grupo de estudiantes que está encarando este proyecto de grado este año van comentando sus avances en este blog.

Hay algunas cuentas de twitter para seguir, que publican siempre info relacionada, y en particular en Uruguay encontramos la del CES y la nuestra:

Conocen alguna otra?

Si bien es bien visible en otros aspectos que la conciencia sobre la importancia de las pruebas de software está creciendo a diario en Uruguay, queríamos mostrar cómo ha crecido también en comunidades web.

Ahora, para no quedarnos sólo con esto, les compartimos algunas otras opciones. Desde hace un tiempo estamos utilizando bastante algunos foros de Linked-in para temas de testing. Si bien el flujo en las preguntas no es tan dinámico como esperábamos, creo que es un buen lugar para hacer preguntas específicas y obtener un poco de feedback de colegas en distintas partes del mundo.

ModelBasedTesting: de ves en cuando llegan invitaciones para eventos internacionales importantes sobre este tema que tanto nos interesa.
OpenSTA: es una herramienta de testing de performance que hemos usado mucho en el CES y que nos ha dado muy buenos resultados. Si bien el desarrollo de la misma está bastante quito hay un grupo de usuarios interesantes en el mundo utilizándola.
Performance Testers: me he suscrito recientemente porque el nombre me llamó la atención y creo que va a valer la pena.
Software Test & Performance Group: este grupo es muy activo y se hacen preguntas siempre interesantes.
SQAforums: para todo lo que quieran de cualquier aspecto del testing este grupo es el indicado.
Abstracta también tiene su grupo si quieren hacer preguntas por ese medio!

Si tienen más RSS o similares interesantes para ser testers informados, compártanlos con nosotros que serán bienvenidos!

Aprovechamos la oportunidad para desearles felices fiestas, y un nuevo año de muy buena calidad!!

Cursos de GXtest 2011

2010-11-24T15:08:00.000-08:00

Ya están las fechas para los cursos que se dictarán de GXtest el año que viene.

Se dictará en tres oportunidades:

Del 14 al 18 de Marzo
Del 13 al 17 de Junio
Del 17 al 21 de Octubre

El curso es presencial y tienen una duración total de 20 horas. En el mismo se aprenden los conceptos principales de GXtest y se ponen en práctica en talleres que abarcan los distintos aspectos aprendidos.

El curso es ideal para todo aquel que quiera comenzar con testing automatizado.

Desde ya los invitamos a todos a registrarse!

Tutoriales de GXtest en video

2010-10-04T13:39:00.000-07:00

Contamos con bastante material de cómo comenzar a utilizar GXtest, cómo comenzar con el test automatizado, pero de todos modos siempre estamos intentando facilitar la adopción de estas buenas prácticas.

Para ello también estamos intentando seguir algo que nos han pedido en reiteradas ocasiones, y en particular en el último post en el que describíamos simples pasos que nos permiten visualizar los beneficios de GXtest en algo que no lleva más de 5 minutos: tutoriales en video.

Para comenzar a experimentar con estas cosas hicimos un primer tutorial siguiendo esos tres pasos descritos en le post anterior que esperemos les sirvan de ayuda. Cualquier feedback es bienvenido.

Update: en cada video, abajo a la derecha está la opción de ver en modo full-screen

Cómo crear un proyecto con GXtest

Cómo grabar un caso de prueba?

Cómo parametrizar una prueba con datapools y luego ejecutar

Estrategia para comenzar a automatizar pruebas

2010-09-27T04:16:00.000-07:00

¿Se acuerdan del juego de PC llamado Star Craft? Alguno tuvo que haber jugado a este juego, o a alguno similar (War Craft, Age of Empire).

Hace uno o dos meses salió una nueva versión, pero yo recuerdo que jugué bastante a la primera. Y bueno, para que más o menos tengan una idea, uno se va formando sus tropas a medida va obteniendo recursos, energía, minerales, etc. Cada nave tiene un costo (en minerales y en tiempo de construcción), y obviamente las grandes naves poderosas, con gran poder destructivo tenían un costo muy alto, y las pequeñas un costo menor. Entonces, uno hasta que no consigue crecer y tener muchos recursos, le cuesta tener una de esas naves gigantes. La estrategia que yo usaba (y me servía mucho mejor que otras que intenté) era construir pequeñas naves, que se rápidamente, con menor poder destructivo pero me van defendiendo como pueden de los posibles ataques, y con el tiempo voy teniendo cada vez más y así uno va logrando su ejército.

En esto de la automatización de pruebas podemos usar la misma estrategia para comenzar. Es preferible hacer una pequeña nave de batalla, que nos de beneficios inmediatamente, por más que sean pocos, que sean rápidamente perceptibles, en vez de esperar a tener una gran nave de batalla superpoderosa, que tal vez llega tarde, cuando ya no hay tiempo para defenderse de los problemas, o sea, cuando estemos por salir a producción! Es mejor hacer pequeñas naves que cuesten menos recursos, y que día a día sumemos una nueva pequeña nave que nos vayan formando un gran ejército de casos de prueba automatizados.

O sea, aplicar soluciones good enough como dice Jodal, y no soluciones perfectas, porque las soluciones perfectas llegan tarde.

GXtest Instalado.

Ambiente para pruebas instalado.

Diseñar primer prueba

- entro a la aplicación (url: http://samples.genexus.com/ajaxsample90/hhome.aspx)

- accedo al menú para crear un nuevo producto

- ingreso los valores

- verifico que el producto haya sido creado haciendo una búsqueda en la grilla

Esta es una prueba muy simple, no estamos intentando "romper el sistema", simplemente estamos viendo "la línea amarilla". Mi primer nave de batalla va a ser bastante limitada.

Automatizar esta prueba con GXtest. Para esto antes que nada es necesario crear un proyecto en GXtest, para lo cual hay que decirle a GXtest cuál es la URL y darle una copia de la KB de la aplicación (para este ejemplo se puede hacer con este XPZ). Esta será como nuestra central de operaciones, donde todas las naves van a reportarse.

Para automatizar el caso de prueba no necesitamos mucho más tiempo que el que lleva ejecutar la funcionalidad a mano, pues efectivamente para grabar un caso de prueba lo que hay que hacer es hacer una ejecución manual de la prueba.

Luego que tenemos esa prueba lista, la podemos ejecutar cada vez que queramos, ... tenemos nuestra primer nave funcionando y reportándose.

Pero podemos con poco esfuerzo más obtener mucho más beneficio de esta misma nave.

Podemos parametrizar la prueba, y hacer que cada valor ingresado en cada campo sea tomado de una tabla de datos de prueba. De esta forma, podremos ejecutar esta misma prueba con muchos datos, y así estar probando distintas situaciones.

Datos de entrada de la funcionalidad: Product Id, Product Name, Product Price, Product Stock.

Entonces tendremos una tabla de datos de prueba (en GXtest es un datapool) con estas columnas. Luego podremos pensar distintas combinaciones de valores para probar. Por ejemplo, pensar ingresar valores nulos, o valores muy grandes, strings muy largos, precios negativos, etc. La misma prueba, que la ejecuté una sola vez, la puedo ejecutar con todas las combinaciones de datos que se me ocurran con tan solo ingresar los valores en una tabla. Esta ejecución la puedo hacer cuántas veces quiera, cada vez que quiera, obteniendo información sobre el estado de la aplicación en forma casi inmediata.

Este enfoque de separar el flujo del caso de prueba de los datos que se utilizan está basado en una técnica llamada Data-driven testing.

Espero el ejemplo les sirva para visualizar cómo se puede ir de menos a más. Lo importante es comenzar, visualizar los beneficios, y luego le vamos a agarrar el gustito, y así iremos haciendo crecer el ejército.

El problema de la acumulatividad nula extrovertida sistemática

2010-09-20T12:04:00.000-07:00

Durante la charla del miércoles se planteó el problema de la acumulatividad nula extrovertida sistemática (el nombre es tan sólo para seguir el mecanismo de nombres de Les Luthiers que lo fui a ver la semana pasada y me gustó mucho:P).

Está basado en algo que se plantea en el libro que ya hemos nombrado y recomendado (Software test automation: effective use of test execution tools, de Mark Fewster y Dorothy Graham, página 494).

En el libro muestran una gráfica parecida a la siguiente:

La misma muestra que las features crecen cada vez más a lo largo del tiempo, pero el test no (no conozco de ninguna empresa que a medida desarrolle más funcionalidades contrate más testers). Eso es un problema, pues significa que cada vez más se nos da la situación de tener que elegir qué testear y qué no, y dejamos un montón de cosas sin probar. El hecho de que las features vayan creciendo con el tiempo, implica que el esfuerzo en testing debería ir creciendo también proporcionalmente. De aquí sale el problema de no tener tiempo para automatizar, pues no hay siquiera tiempo para el test manual, y tal vez la mayoria de uds no son conscientes de que les sucede esto o de la gravedad del asunto.

Un colega argentino de una consultora (Ernesto Kiszcurno) dice que lo más pesado (costoso) en testing es diseño y ejecución. Podríamos considerar que el diseño es acumulativo, pues vamos diseñando y registrando en planillas de cálculo o documentos. El problema es que la ejecución de pruebas no es acumulativa. Cada vez que liberamos una nueva versión del sistema es necesario (deseable, sería necesario) testear todas las funcionalidades acumuladas, y no sólo las del último incremento, pues tal vez funcionalidades que se implementaron en versiones anteriores cambian su comportamiento esperado por "culpa" de los últimos cambios.

Lo bueno de la automatización es que es acumulativa. Es la única forma de hacer que el testing se haga constante (sin que se requieran más esfuerzos a medida pasa el tiempo y crece el software a probar).

El desafío es hacer testing en forma eficiente, de forma que nos rinda, que veamos los resultados, que nos aporte valor, y que vaya acompañando la acumulatividad del desarrollo.

Ojo! los casos de prueba tienen que ser fácilmente "mantenibles" sino no se puede lograr esta acumulatividad y acá es donde GXtest le da otra ventaja a la comunidad GeneXus respecto a las otras tecnologías.

Nuestra propuesta es automatizar pruebas funcionales para hacer testing en forma más eficiente, y así ganar más confianza en nuestro software.

Este era el mensaje de la charla. Esperamos les haya gustado, y que algo de lo planteado les sirva para mejorar el trabajo de todos los días.

Les recomiendo en particular alguna cosita de Lutherapia, que es el espectáculo que dieron Les Luthiers en estos días acá en Montevideo:

#XXGX - Agradecimientos

2010-09-17T08:32:00.000-07:00

Se vivió otro encuentro GeneXus. Como se comenta en cada pasillo: año a año nos supera las expectativas, algo muy difícil de lograr.

Quedamos felizmente sorprendidos (como mencionamos en el post anterior), de cómo año a año se habla mucho más de testing. Hubo durante toda la mañana del miércoles, charlas de testing, las cuales estuvieron muy concurridas. El laboratorio de GXtest albergó a 40 usuarios y quedaron muchos sin posibilidad de realizarlo. Confiados en que estamos en el camino correcto, apostando a que se profesionalice cada vez más el testing, como parte clave del éxito de las empresas de TI.

Queremos agradecer a: Enrique Almeida (Concepto), Gabriela Rial (K2B) y Eliene Balosian(Cybernet) que dictaron esta muy buena charla sobre su experiencia con la adopción y el uso de GXtest.

A Úrsula Bartam y Alejandro Blengio por su continuo apoyo a GXtest y la organización del laboratorio.

A Gisela Bertelli y Gerardo Pizarro por ayudarnos en toda el área comercial.

A José Lámas por ser un gran profesional que invierte tiempo y pienso en GXtest.

A Artech por confiar en nosotros.

Les dejo una entrevista de pasillo que nos realizaron a Federico, Matías y a mi.

XX Evento Internacional GeneXus - Testing Track

2010-09-08T15:15:00.000-07:00

Como cada año, Artech organiza el Evento Internacional GeneXus. Este gran evento reúne a miles de personas de todos lados en Montevideo.

Nosotros desde Abstracta estaremos participando en algunas instancias.

Lunes 15 hs - Elevator Speech de GXtest: dentro del grupo de charlas de Elevetor Speech: Productos GeneXus, Fabián estará contándoles en 5 minutos de qué se trata GXtest y en qué los puede ayudar. Ideal para una primera aproximación al producto y al testing automatizado.
Martes 14:30 hs - Laboratorio de GXtest: para todos aquellos que quieran probar GXtest para entender mejor de qué se trata y cómo funciona, lo invitamos al laboratorio de GXtest. En una hora van a poder automatizar varios casos de prueba!
Miércoles 11:45 - Testing: el camino para que confíen en nuestro software: junto a Federico se verán algunas formas de resolver los principales desafíos que se encuentran en el camino de hacer testing como para obtener el mayor beneficio.
Miércoles 12:15 - Probando aplicaciones GeneXus con la ayuda de GXtest: Enrique, Gabriela y Eliene estarán compartiendo su experiencias al utilizar GXtest para probar sus aplicaciones.

Por otro lado hay varias charlas de testing a las cuales nos gustaría invitarlos. En este link las pueden encontrar todas.

El Centro de Ensayos de Software de la mano de Mónica Wodzislawski, Gustavo Guimerans, Christian Pla, Michel Camarotta, va a estar presentando las siguientes charlas más que interesantes: Probar para corregir, probar para decidir, Pruebas de performance en aplicaciones Win-GeneXus y Testeabilidad: ¿la otra cara del testing?

Por otro lado desde GeneXus Consulting, Natalia Dimu y Mauro Alvez cuentan qué más podemos hacer que nos permita potenciar la efectividad de las pruebas en la charla GXC Development Framework: testing , keep walking.

Año a año van creciendo las ponencias respecto a los temas de calidad y testing y creemos que este es otro motivo para seguir el slogan de: Let's celebrate!

Resultados de: ¿Qué es el testing? y ¿para qué me sirve?

2010-08-25T19:25:00.000-07:00

Para concluir el juego propuesto en el post anterior, les queremos dejar antes que nada un agradecimiento a los que se coparon con la idea y colaboraron, y un link al resumen de todas ellas.

Como podrán ver, algunos más y otros menos, pero cada cual tiene su visión de los beneficios que nos brinda el testing. Nos interesa en particular compartirles otra definición dada por Cem Kaner (un gurú en el tema)

It is an empirical technical investigation conducted to provide stakeholders with information about the quality of the product or service under test.

Y de ahí en particular destacar que es un proceso empírico, se basa en la experimentación, en donde se le da información sobre la calidad de un producto o servicio a alguien que está interesado en el mismo.

En base a los beneficios que uno persigue es que se establecen los objetivos, y tal como se ve en las respuestas los beneficios pueden ser muy distintos de organización en organización.

Si el objetivo del testing es encontrar la mayor cantidad de errores posibles, entonces seguramente el testing se enfoque en las áreas más complejas del software o las que han tenido más defectos. Si el objetivo es dar seguridad a los usuarios, entonces seguramente se enfoque el testing en los escenarios más usados por los clientes. Ojo!, este objetivo no tiene porque ser el mismo a lo largo del tiempo, pero sí es importante que se tenga claro en cada momento cuál es.

Ahora bien, hemos hablado de los objetivos del testing en general, pero qué objetivos tiene en particular el testing automatizado?

Si bien podemos pensar en que los objetivos del testing automatizado son triviales pueden también diferir mucho de una organización a otra.

En el libro Software test automation: effective use of test execution tools" de Mark Fewster & Dorothy Graham" que mencionamos en un post anterior se mencionan algunos objetivos interesantes como para comentar:

Testing consistente y repetible
Correr casos de prueba desatendidos
Encontrar errores de regresión
Correr casos de prueba más seguidos
Mejorar la calidad del software
Testear más profundo
Mejorar la confianza en la calidad del software
Testear más software
Incrementar la confianza de los usuarios
Medir performance
Reducir el costo del testing
Encontrar más errores
Testear en diferentes sistemas operativos
Disminuir el tiempo de salida al mercado/correr las pruebas más rápido
Mejorar la moral en los testers
Testear en diferentes bases de datos

Creemos que si bien hay varias parecidas, es preciso antes de comenzar con cualquier proyecto de automatización preguntarse cuál de estos objetivos queremos lograr y cómo medir si nos acercamos a los objetivos o no.

Muchas gracias nuevamente a todos!

Juego Juego: Qué beneficios tiene el testing?

2010-08-11T04:08:00.000-07:00

Hace un tiempo Fede tuvo una iniciativa muy interesante: preguntar a cada uno en la empresa:

¿Qué es GXtest? y ¿Qué beneficios tiene?

Con los resultados de esta encuesta, pudo ver si todos teníamos la misma idea sobre tan importantes respuestas.

Nos gustaría invitarlos a jugar a ustedes y que se pregunten:

¿Qué es testing? ¿Qué beneficios tiene?

Si cada uno se anima a preparar un mail para la interna de su empresa, haciendo estas dos preguntas, luego pueden enviarnos (de manera anónima) las respuestas, nosotros las analizaremos y publicaremos un resumen del análisis de las empresas de la comunidad en otro post. Si además quieren agregar qué rol en la organización tiene cada uno de los que contesta las respuestas, entonces vamos a tener aún más información interesante.

Creemos que puede ser muy bueno ver estos aspectos en la comunidad.

El resumen con las respuestas obtenidas, las deben enviar a:

"Automating chaos just gives faster chaos"

2010-08-06T05:57:00.001-07:00

El que crea que una herramienta soluciona todos los problemas .... tiene un nuevo problema.

En general (y creo que más aún en el mundo de las TICs) buscamos una herramienta que solucione todos nuestros problemas. El tema es que no es suficiente con tener una buena herramienta para realizar un buen trabajo.

"Automating chaos just gives faster chaos"

Es una de las frases citadas en el libro "Software test automation: effective use of test execution tools" de Mark Fewster & Dorothy Graham, que si bien el libro tiene ya varios años, es muy recomendable para todo aquel que vaya a comenzar con automatización de testing.

En este artículo, en el que se le consulta a distintos expertos en el área, uno de los planteos que se hacen es que es conveniente atacar el problema en pequeñas partes, armar una pequeña suite de pruebas automatizadas que nos den beneficios lo antes posible, a esperar a armar un gran barco de batalla que ataque todos los problemas de una. El problema de ese segundo enfoque es que seguramente el gran barco esté pronto para cuando la guerra esté a punto de terminar, o sea, un mes antes de la fecha de salida en producción.

Esto es también lo que plantea GeneXus en el desarrollo, o sea un enfoque iterativo e incremental en el cual se vayan obteniendo resultados desde fases tempranas.

Así como GeneXus lo hace posible en desarrollo GXtest lo hace posible en testing ya que permite hacer evolucionar el conocimiento en testing a media que avanza el entendimiento de la realidad y la construcción de la aplicación.

Curso Técnicas de Testing Combinatorio y de Mutación

2010-08-05T07:53:00.000-07:00

En Facultad de Ingeniería se repetirá la semana próxima el curso de Técnicas de Testing Combinatorio y Mutación, a cargo del profesor Macario Polo de la Universidad de Castilla - La Mancha, España. Podrán ver más información aquí. Se repetirá los días lunes 9, miércoles 11 y jueves 12 de agosto, en el horario de 19 a 23 hs.

En particular ya tuve la oportunidad de hacerlo dentro del CES, y me resultó más que interesante, principalmente pensando en cómo un desarrollador puede utilizar herramientas y técnicas para generar datos de prueba, en forma eficiente en búsqueda de mejorar la calidad de lo que desarrolla.

Las herramientas utilizadas y los ejemplos que se muestran son en Java, pero pueden aplicarse para cualquier otro ambiente de desarrollo. Incluso, hay herramientas que se presentan que se pueden utilizar para testing funcional, incluso manual, por lo que es aprovechable para distintos roles dentro de una organización.

Les recomiendo a quien pueda hacerlo que lo haga.

Data-Driven Testing con Datapools

2010-07-28T13:42:00.001-07:00

Nos pareció interesante este artículo, en donde habla de cómo hacer pruebas dirigidas por datos utilizando datapools, basado en la herramienta de testing automatizado de IBM-Rational, escrito por uno de los gurúes del testing Michael Kelly.

La definición dada de Data-driven Testing es muy simple: para scripts de testing automatizado, data-driven testing implica probar la aplicación utilizando datos tomados de una fuente de datos, como una tabla, archivo, base de datos, etc en vez de tener los mismos fijos en el script. En otras palabras, parametrizar el test case, permitir que se pueda ejecutar con distintos datos. El objetivo principal es poder agregar más casos de prueba simplemente agregando más datos.

Para el caso de GXtest, una fuente de datos puede ser

datapools: formato tabular (filas y columnas)
de la base de datos accedidos con procedimientos GeneXus
datos tomados de pantalla

El más común, o el que se visualiza bien fácil, es el primero, tomando los datos de datapools.

Cuándo se obtienen los mayores beneficios aplicando esta técnica?

Aplicaciones que tienen muchos flujos de datos. Se podría especificar en el datapool las condiciones que se quieren probar en la prueba, y tener un script que contemple muchos casos, pasando por distintos flujos según los datos especificados en el datapool.
Aplicaciones que tengan distintas respuestas según las entradas ingresadas (cualquier sistema de información), pues en el datapool será interesante guardar tanto los datos de entrada como los datos esperados para los mismos, y así se pueden validar los datos esperados.
Grandes aplicaciones desarrolladas en varias iteraciones. En el proceso de desarrollo, a medida varíe la lógica, los estilos y look and feel de la aplicación, seguramente los datos a ingresar no varíen tanto, y sea de gran utilidad verificar que la funcionalidad sigue comportándose como se esperaba.

Generalmente se tienen datos de pruebas documentados en planillas de cálculo, y es por eso que GXtest brinda la facilidad de cargar un datapool desde un archivo CSV (este es un formato en el que se puede guardar los datos de prueba directamente desde la planilla de clálculo).

Como para cerrar, se pueden utilizar datapools para orientar las pruebas, y esto puede ser tan simple o complejo como se quiera o requiera. La estrategia en sí tiene mucho potencial.

Relación Scripts-Casos de Prueba

2010-07-23T07:09:00.000-07:00

En una discusión de un grupo de Linked-in (relacionado con testing y calidad) se debatió sobre un tema interesante que involucra ciertas ideas de diseños de casos de pruebas que siempre están sobre la mesa a la hora de automatizar.

¿Cómo deberían hacerse los scripts (test cases en GXtest)? ¿uno por caso de prueba, o puedo hacer un script que pruebe distintos casos de prueba?

Como todo en la ingeniería de software, esto depende del caso de prueba. Algunos plantean pensar en cuántas bifurcaciones lógicas se dan en el caso de prueba. Lo más adecuado (nos parece, pensando en GXtest) es tomar el enfoque modular que plantean en la discusión. O sea, tener distintos módulos (scripts) que hagan distintas partes de la prueba, y luego un script que orqueste todas estas partes. De esa forma podemos reutilizar las pequeñas partes y hacer distintas pruebas que las compongan de distintas formas.

En ese caso la relación sería un caso de prueba hecho con varios scripts.

Ventajas

mantenimiento: más fácil de mantener, se pueden reutilizar los módulos, se puede cambiar el flujo en distintos niveles, el script del Test Case queda más legible, pues se puede ver todo el flujo que recorre a "gran escala", y luego profundizar en las partes que interese. Con GXtest es muy sencillo navegar entre los distintos scripts.
cambiar el flujo del caso de prueba: se puede manejar más fácil el flujo del caso de prueba, y hacer por ejemplo que cierto módulo se repita una cantidad dada (fija o variable) de veces (el típico ejemplo de una factura, si modularizamos la parte donde ingresamos una línea de la factura, con cierto producto y cantidad, podemos hacer que esa parte se ejecute distinta cantidad de veces, con el fin de probar la factura con distintas cantidades de líneas)
análisis de resultados: es más sencillo analizar los reportes de resultados

Si se tiene documentación de casos de prueba (si se solían ejecutar manualmente por ejemplo) una buena práctica podría ser llevar una matriz que relacione los casos de prueba con los distintos scripts involucrados. Esto permite conocer también qué verificar cuando cambien requerimientos que tengan impactos sobre ciertas pruebas, y así consecuentemente sobre algunos scripts.

¿Que enfoque utilizan en sus empresas?

Período de beta extendido

2010-06-01T12:02:00.000-07:00

Aunque habíamos terminado de dejar estables las nuevas funcionalidades de la versión beta de GXtest, hemos decidido extender el período de beta testing con el fin de incluir algunas mejoras especialmente en la funcionalidad de impactar cambios de la KB a los Test Cases.

Esto es útil para cuando tenemos automatizadas algunas pruebas sobre algo que cambió, y eso implica que sea necesario hacer algún mantenimiento a los test cases.

Los cambios pueden ser

- se agregaron o eliminaron objetos

- se cambiaron tipos de atributos

- se cambiaron nombres o propiedades

- etc.

O sea, cualquier cambio introducido por el simple hecho de seguir desarrollando.

Entonces, ante cada cambio que tenga impacto sobre alguna prueba (imaginemos que una prueba incluía hacer un clic sobre un elemento que fue eliminado) se generará un conflicto el cual debe ser resuelto.

Muchos conflictos GXtest los puede resolver automáticamente, dado que GXtest conoce sobre GeneXus (es la diferencia principal con el resto de las herramientas de automatización, es la ventaja que tiene por ser específica para GeneXus), y algunos requerirán cierta asistencia del usuario, más que nada porque los cambios pueden deberse a cambios en requerimientos, y si antes se debía hacer clic en un botón, y ese botón se eliminó, el usuario (tester) debería indicar con qué acción se reemplazará esto.

Mientras más facilitemos esta funcionalidad, más ágil será la interacción entre el equipo de testing y el de desarrollo, permitiendo así generar ciclos más cortos de liberaciones de versiones, pudiendo conocer el estado de la calidad de nuestros sistemas en forma más temprana, reduciendo así los costos de corrección de defectos por ejemplo.

Los invitamos a probar esta nueva funcionalidad en el próximo build y escuchamos todas sus sugerencias para mejorarla aún más.

Trabajar con Balloons en GXtest

2010-04-26T13:47:00.000-07:00

Una de las cosas que se mejoraron en el período de betatest de GXtest 1.1 fue el soporte para realizar validaciones sobre Balloons.

Los Balloons son los elementos que nos permiten, en Genexus, mostrar mensajes de error o de advertencia contextualizados.

En la imagen se puede ver el error No matcvhing 'Country' sobre el elemento CountyId.

Hoy con la liberación de la RC se puede realizar las siguientes acciones con balloons:

Las validaciones pueden expresar lo siguiente:

que aparezca un balloon cualquiera
que no aparezca un balloon cualquiera
que aparezca un texto en un balloon de tipo advertencia
que aparezca un texto en un balloon de tipo error
que no aparezca un texto en un balloon de tipo adevertencia
que no aparezca un texto en un balloon de tipo error

Hoy en día los parámetros son:

AppearBalloon

parar o no ante error
Negación
Control
mensaje de error

VerifyControlValdiation

parar o no ante error
Negación
Control
mensaje
tipo de balloon
mensaje de error

Los primeros dos parámetros y el último están en todas las validaciones.

Esto es algo muy común a utilizar al probar aplicaciones Genexus, y gracias a sugerencias y necesidades de Alejandro y Úrsula lo incluimos en esta versión.

Por más información ver

Reproducir un defecto detectado

2010-04-05T12:33:00.000-07:00

Nos han solicitado varias veces funcionalidades para simplificar la "reproducibilidad" de un bug encontrado (detectado) o para poder ver fácilmente a qué parte del modelo del caso de prueba se corresponde el resultado que se está observando.

Por eso en el build número 1273 recientemente liberado podremos encontrar que se agregó una funcionalidad simple, pero de gran utilidad para esto. Cuando se está observando el resultado de una prueba, se puede hacer un doble-clic sobre el elemento y de esa forma ir directamente al modelo de prueba que corresponde, posicionándose directamente sobre el nodo y comando que detectó el error (o que dio resultado de error) o no... Esto simplificará mucho la tarea de "debug" del caso de prueba.

Hay más ideas rondando, y otras cosas que se han hecho para esto (como guardar las HTML de las respuestas, las imágenes en JPG, los datos usados de prueba), pero sería interesante saber cómo les quedaría más cómodo poder asociar un resultado con el fallo, o con la prueba en sí, ... cualquier comentario es bienvenido y será tenido en cuenta :)

"Aclarando" la Caja Negra...

2010-03-24T02:00:00.000-07:00

Uno de los enfoques más utilizados para hacer testing es el de Caja Negra, en donde el tester no "ve" el código de la aplicación sino que se basa en las entradas y condiciones que afectan el comportamiento del sistema bajo prueba y en sus salidas.

El tema de Caja Negra viene por contraposición a Caja Blanca (que debería ser caja transparente) en donde uno se basa en como está hecha la aplicación para generar casos de prueba.

Hoy quisiera hacerles una propuesta para "aclarar" la Caja Negra.

Cuando se está testeando una aplicación GeneXus, hay mucha información que está en la misma (precisamente en la KB) que es fácilmente entendible por el tester aunque el mismo no sepa GeneXus. Entonces, ¿por qué no mostrarle fácilmente al tester esta información para que pueda "apuntar" mejor sus pruebas o para que pueda hacer una especie de revisión de programa a medida que va probando?

¿Qué información puede ser útil?:

Definición de los atributos y variables: el tipo de cada atributo y variable
Reglas: todas las reglas son de utilidad y en especial aquellas de errores y advertencias
Condiciones dentro de los eventos: poder saber cuales son aquellos factores que hacen que se siga un flujo u otro puede ser muy útil para hacer casos de prueba. Por ejemplo, para simplificar esto se puede hacer un diagrama que ilustre esta información.
Documentación
etc, etc

¿Cómo implementar esto?

Lo que hicimos en Abstracta es un panel vertical a la izquierda de la pantalla en el navegador, que a medida que se va navegando a cada página va mostrando dicha información. Les muestro unas imagenes de lo que tenemos hasta ahora:

Un problema que podría traer esta estrategia es sesgar al tester a que piense igual que el desarrollador o con la misma "lógica".

¿Que les parece la idea? ¿Piensan que les ayudaría a hacer mejor testing?

Los que la crean interesante los invitamos a aportar en la misma y mejorarla, ya que hemos presentado un Collaborative Project del cual pueden encontrar más info acá.

Proyectos de fin de carrera sobre testing en la Fing-UdelaR

2010-03-18T05:50:00.000-07:00

Hay algunos temas relacionados al testing que nos resulta muy interesantes de investigar. Generalmente estos muy volcados hacia la comunidad GeneXus.

Junto con el Centro de Ensayos de Software hemos decidido presentar como proyecto de grado (proyecto de fin de la carrera) algunas de estas ideas.

Queremos entonces invitar a dos cosas, por un lado a todos los estudiantes que estén buscando proyecto de grado en esta área a que nos contacten para desarrollar estos proyectos, y por otro, a todos los interesados en estos temas para que aporten sus ideas, feedback, etc.

Los proyectos son los siguientes:

Generación automática de casos de prueba para aplicaciones GeneXus: en pocas palabras la idea es analizar como generar casos de prueba de manera automática combinando técnicas de testing con la información que tenemos en la propia aplicación GeneXus u otra información que se pueda agregar.
GXUnit: la comunidad GeneXus requiere una herramienta que le permita hacer testing unitario a los desarrolladores. Hay varios esfuerzos hechos por la comunidad GeneXus y la academia en la construcción de esta herramienta. Enrique en su blog nos ilustra bastante sobre este proceso. La idea del proyecto de grado es hacer un estudio del estado del arte sobre las herramientas de testing unitario y luego conciliando los distintos enfoques con el desarrollo en Genexus proponer y desarrollar GXUnit.

En los links podrán ver más información en detalle.

También el CES presenta este otro proyecto que está muy intereante:

Búsqueda y/o generación automática de datos requeridos para ejecutar los casos de prueba diseñados para el testing de sistemas de información

A los estudiantes que quieran embarcarse en estos proyectos les ofrecemos todo el apoyo de Abstracta y el CES en estos temas así como también de Artech y de destacados miembros de la comunidad GeneXus.

Testing automatizado - hagamos que las máquinas trabajen por nosotros

2010-03-08T06:24:00.001-08:00

Si recuerdan, el año pasado en el Encuentro GeneXus en Montevideo, estuvimos a cargo de dos charlas y un café (en conjunto con el CES). En una de las charlas hablamos sobre el testing automatizado, con el fin principal de mostrar los distintos desafíos que se presentan y la forma que tenemos de enfrentarlos, en particular al trabajar con Genexus, para que así se animen a comenzar a automatizar.

Como seguimos con la apuesta a que se animen a automatizar les damos dos anuncios

1ro - salió el primer build después del despegue de la beta. Les recomiendo leer aquí para que puedan descargarla, y para que vean los avances que se han logrado desde la beta. Queremos hacer énfasis en que este es el mejor momento para dar feedback sobre el producto, pues nuestro foco en este momento está ahí.

2do - transcribimos la charla a nuestra documentación, a modo de transmitir mejor las experiencias obtenidas en el transcurso de nuestra historia en el testing automatizado de aplicaciones Genexus (acceda aquí).

Entonces todos a Automatizar!

Esperamos sus comentarios.

GXtest 1.1 beta released!!

2010-03-02T04:34:00.000-08:00

Tenemos el agrado de anunciar que la versión beta de GXtest 1.1 está en la calle!

Nuestro objetivo fue el de brindar la nueva versión con todas sus nuevas funcionalidades servidas para que les sea práctico y fácil probarlas y visualizar sus ventajas, y las mejoras que ellas le traen a GXtest. En ese sentido hemos actualizado la documentación mejorando los tutoriales y guías para comenzar fácilmente a agarrarle el gustito al testing automatizado.

¿Cómo arrancar?

Primero debes registrarte al equipo de betatesters, luego descargarte la última versión disponible, y comenzar a probar. Eso lo debes hacer aquí.

En ese momento también tendrás acceso al foro para poder intercambiar dudas y experiencias sobre la herramienta. Todo el feedback que nos aportes será bienvenido y agradecido.

¿Dónde está la información técnica?

Está todo centralizado en nuestra Wiki junto a toda la documentación de GXtest, en este link. Ahí podrás encontrar una descripción de las nuevas funcionalidades, las mejoras implementadas, y una serie de lecturas recomendadas para comenzar.

Nivel de abstracción de los Casos de Prueba

2010-02-11T13:26:00.000-08:00

Un concepto simple de testing que se utiliza en GXtest dando mucho valor a los testers que van a trabajar diseñando pruebas es el de Data Driven Testing.

Este concepto permite diferenciar entre casos de prueba abstractos (o conceptuales), y casos de prueba concretos (o con datos).

Nos ha pasado que las empresas nos plantean que en su organización se cuenta con un conjunto de pruebas de regresión formado por miles de casos de prueba, pero ¿cómo se da esto? es porque estamos contando casos de prueba con datos y no casos de prueba abstractos. Veamos con un ejemplo, si estuviéramos probando el login de la aplicación:

Test case 1: probar con un usuario vacío y verificar que no entra

Test case 2: probar con password vacío y verificar que no entra

Test case 3: probar con usuario valido y password inválido y verificar que no entra

Test case 4: probar con usuario y password válidos y verificar que sí entra

Esto lo podríamos ver como un solo caso de prueba que sea

1.- ingresar usuario

2.- ingresar password

3.- botón login

4.- verificar resultado

que luego tenga "parametrizadas" sus entradas y verificaciones. O sea, que tome usuario y password y resultado esperado de una fuente de datos donde tenga las siguientes líneas

usuario vacio, password cualquiera, no entra

usuario cualquiera, password vacio, no entra

usuario válido, password inválido, no entra

usuario válido, password válido, entra

Entonces, de esta forma separamos el caso de prueba abstracto de sus instancias. Por un lado tenemos el caso de prueba abstracto que me dice qué hace el caso de prueba, y por otro lado tengo los datos con los cuales se va a "instanciar" el mismo. Cada caso de prueba concreto es una prueba diferente para la aplicación.

Ventajas

Podemos describir el flujo de la aplicación en el modelo independiente de los datos
Podemos tener en forma centralizada los datos de entrada y salidas esperadas en una tabla (o Excel)
Podemos agregar más casos de prueba simplemente agregando líneas a la tabla
Relacionado con el post anterior los casos de prueba expresados de esta forma van a constituir una mejor documentación de la aplicación.

Entonces, seguramente cuando alguien intente diseñar casos de prueba con GXtest deberá pensar las cosas en forma un poco distinta a lo que algunos suelen hacer. Debería ser en dos etapas, primero pensar el caso de prueba a nivel conceptual, y luego bajarlo a instancias con distintos datos. El otro camino es el inverso, si ya se tienen pensados varios casos de prueba con datos, antes de automatizarlos con GXtest se debería pensar si no se pueden conceptualizar o abstraer esos casos de prueba.

Qué dicen, les resulta más simple de esa forma?

La idea es seguir la filosofía GeneXus: Simplifiquemos las cosas haciendo nuestras tareas en forma más descriptiva y abstracta.

How to write a good test case: 5 tips to write better test cases

2010-02-09T07:10:00.000-08:00

Leyendo este artículo sobre como escribir buenos test cases, me pareció importante relacionar estos 5 consejos con GXtest.

1) Escribir un caso de prueba para todas las condiciones

Cuando estamos hablando de código GeneXus tal vez esto sea como pensar no sólo en los distintos flujos que se dan en los procedimientos, sino en que se verifiquen las regla definidas sobre un objeto (ojo, no estamos diciendo de cubrir todo el código, ni que cubrir todo el código nos garantice nada).

2) Testear solo una cosa

Si bien con GXtest nos podemos ver tentados a testear varias cosas en un mismo Test Case, es conveniente mantener aisladas las pruebas para cada parte del sistema.

3) Hacer que los casos de prueba describan cómo trabaja el sistema

En GXtest describimos las pruebas con modelos simples, y esto hace que se describa el comportamiento esperado del sistema en forma sencilla. Hay algunos elementos que ayudan con este propósito. Por un lado se pueden poner comentarios de texto en los casos de prueba. Por otro lado podemos "partir" nuestro caso de prueba en varios sub-casos para lograr que luego cuando se vea en su generalidad se pueda entender los distintos pasos que se dan de manera más fácil.

4) Organizar los casos de prueba de manera consistente

GXtest permite utilizar folders (podrán verlo a partir de la beta 1.1) para organizar tanto los casos de prueba como los datos de prueba. Es importante tal como dice el artículo fijar un criterio para toda la empresa o por proyecto y seguirlo a rajatabla.

5) Hacer casos de prueba "FIRST class"

Fast: GXtest se encarga de ejecutar los casos de prueba lo más rápido posible. En Abstracta es un desfío constante bajar los tiempos de ejecución de cada caso de prueba sin perder en estabilidad.
Independent: en las suites de GXtest se agrupan varios casos de prueba. Es importante que en la suite puedan correr sus casos de prueba sin importar el orden.
Repeteable: es deseable que cada caso de prueba se pueda repetir sin tener necesidad de hacer un restore de la base de datos. Para eso GXtest proporciona mecanismos para acceder a los datos utilizando procedimientos GeneXus, los cuales se pueden utilizar para borrar datos, obtener datos, etc.
Small: casos de prueba gigantes no pueden cumplir con el primer requsitio Fast. Si bien con GXtest nos podemos tentar a hacer casos de prueba muy grandes es conveniente siempre mantener su tamaño acotado.
Transparent: en GXtest se puede utilizar la descripción que tiene asociado cada caso de prueba para indicar claramente su propósito.

Es bueno para nosotros, a modo de validación, ver cómo con GXtest podemos adaptarnos a los buenos tips que se recomiendan en distintas fuentes.

¿Cómo comenzar con el testing automatizado?

2010-01-24T14:00:00.000-08:00

Acabamos de terminar una documentación en nuestra wiki, la cual nos resultó interesante compartirla también por este medio (fuente: http://gxtest.abstracta.com.uy/wiki/index.php?title=%C2%BFComo_empezar_con_testing_automatizado%3F)

Muchas veces se visualizan los beneficios de automatizar parte de las pruebas pero no se sabe como comenzar, o se cuenta con una herramienta de testing automatizado pero no se está seguro acerca de su implantación. Por estos motivos en este artículo se discutirán los distintos aspectos importantes a tener en cuenta para comenzar con el testing automatizado, en particular utilizando GXtest sobre aplicaciones GeneXus, aunque varios de los conceptos y consejos que se mencionan aquí aplican a cualquier intento de automatización.

Comenzar con un proyecto piloto

Al igual que la mayoría de las prácticas de ingeniería de software, es conveniente elegir un proyecto adecuado y utilizarlo como proyecto piloto para comenzar.

El hecho de utilizar un proyecto piloto tiene varias ventajas:

poder definir una metodología inicial adecuada a la forma de trabajo de la empresa
adquirir experiencia en el uso de las herramientas de automatización
medir los beneficios
evaluar las dificultades
contar con un proyecto de alcance acotado en el cual focalizar los esfuerzos por mejorar la calidad

Es deseable que este proyecto piloto pueda mostrar en el menor plazo posible el ROI que se tiene al aplicar testing automatizado, por este motivo se deben seleccionar algunas métricas (de acuerdo a la realidad de la empresa y del proyecto) que lo visualicen. Algunas métricas que se pueden utilizar para este fin son las siguientes:

horas de testing / # de errores encontrados por el cliente
# de errores encontrados por el cliente / Tamaño del sistema
Tiempo de detección de los errores (entre que se introdujo el error y se detectó)
etc

También se puede evaluar a través de un cuestionario algunos aspectos subjetivos como son la motivación del equipo de testing, la sensación de estabilidad o calidad del sistema por parte de los usuarios o la percepción de calidad en el testing de los desarrolladores.

Ahora bien, ¿cuales son las características deseadas que tiene que tener el proyecto piloto?. Algunas de estas características son:

Tamaño del equipo pequeño: es preferible que el equipo de testing y el equipo de desarrollo sean pequeños. En equipos pequeños es más fácil introducir cambios y medir su impacto. Un factor muy importante es que el equipo vea el testing automatizado como una ayuda en su trabajo y no como una carga extra.
Skills de las personas involucradas: si se va a introducir un cambio es imprescindible contar con gente dispuesta a cambiar la forma de trabajo. Si esta gente es líder o referente en la empresa mucho mejor, ya que luego será más sencillo adoptar los cambios en el resto de los proyectos.
Cantidad de ciclos de prueba: las pruebas automatizadas tienen más valor cada vez que se corren, por este motivo aquellos proyectos que involucren varios ciclos de prueba son los que sacan más valor de este tipo de pruebas. Típicamente durante la etapa de mantenimientos de los sistemas se tienen algunas correcciones del mismo y luego se corren pruebas de regresión. Estos proyectos de mantenimiento suelen ser buenos candidatos para empezar con las pruebas automatizadas
Relevancia de la calidad del sistema: si bien todos los sistemas que desarrollamos tienen que ser de calidad, hay ciertos proyectos en los cuales los clientes son más demandantes en cuanto a la calidad y valoran más los aspectos referentes a la calidad.
Tecnología a utilizar: dependiendo de la tecnología que se utilice para desarrollar existen herramientas para automatizar de menor o mayor sofisitificación y de menor o mayor precio. Para el caso en que la aplicación se realice en GeneXus con GXtest se tendrán contemplados los distintos aspectos que necesita cubrir la herramienta, con otras tecnologías hay que evaluar otras alternativas.

¿Quién automatiza?

Una vez que se decidió del portfolio de proyectos, cual será el elegido para comenzar con la experiencia de testing automatizado se deberá asignar las personas que se involucrarán en el mismo. En particular se deberá elegir quienes serán los encargados de realizar el testing automatizado. La recomendación es que las personas encargadas de automatizar sean los mismos analistas que conocen de los requerimientos y de la realidad y que realizan el testing funcional tradicional. Es importante que sea el mismo grupo por varios motivos:

que no se genere competencia entre las pruebas manuales y las pruebas automatizadas
ayudar a asegurar la correcta elección de las pruebas que se realizarán de manera automatizado
las herramientas de testing automatizado pueden servir no solo para automatizar casos de prueba sino que también para generar datos para los casos de prueba. Por este motivo conocer de la herramienta de automatización ayudará a también en las pruebas manuales

¿Cómo formar a las personas que van a automatizar?

El proceso que siga cada una de las personas que vaya a automatizar puede variar según su grado de conocimiento en testing automatizado y en herramientas de automatización. Es aconsejable que de manera paralela puedan comenzar con la capacitación en la herramienta que se vaya a utilizar (con GXtest se puede empezar por ejemplo con Tutorial de GXtest Designer) así como también leyendo material acerca de metodología y experiencias de pruebas automatizadas en general. Una lectura recomendada es la 4º Edición de la revista Testing Experience dedicada al testing automatizado.

Selección de los casos de prueba a automatizar

Una vez que se tiene elegido el proyecto y la gente que participará en el mismo el punto crítico en la automatización de las pruebas es decidir cuales casos de prueba se automatizarán. El error más común en los intentos de automatización es intentar automatizar todo, así que la recomendación aquí es NO INTENTE AUTOMATIZAR TODOS LOS CASOS DE PRUEBA. Teniendo una visión del negocio y también de la estructura interna del sistema (para lo cual se necesita involucrar a los desarrolladores) se debe decidir cuales casos de prueba que se automatizarán. Algunas de los factores a tener en cuenta son:

¿cuales casos de prueba se necesitarán correr más veces durante el proyecto? Típicamente aquellos casos de prueba asociados al núcleo de la aplicación se pueden construir al principio del proyecto y luego sirven (adaptándolos cuando sea necesario) para el resto de la vida del sistema.
¿cuáles casos de prueba conllevan mucha dedicación humana y son repetitivos? Hay veces que un caso de prueba requiere de un trabajo tedioso para configurar el ambiente de prueba y luego ejecutar el caso de prueba. Estos casos de prueba es bueno automatizarlos para liberar el recurso humano y que pueda dedicarse a otros casos más desafiantes.
¿que funcionalidades son críticas para el cliente/usuario? Aquellas funcionalidades que tienen que andar si o si en cada entrega generalmente es interesante incluirlas en los casos automatizados.
¿que costo tienen asociado la automatización del caso de prueba? Hay casos de prueba que son muy difíciles de automatizar, ya sea porque hay que realizar validaciones visuales complejas o por otras razones. Por este motivo si el costo de su automatización es grande hay veces que es mejor dejarlo para ser ejecutado manualmente.

Teniendo en cuenta estas características se puede ponderar cada caso de prueba en base a cada una de ellas para luego hacer un ranking o priorizar los casos de prueba a automatizar.

En el caso de que se vaya a automatizar en un proyecto de mantenimiento en el cual ya se están corriendo pruebas manuales, muchas veces la fuente de información más importante que tenemos para elegir los casos de prueba a automatizar es el historial de incidentes. Con este instrumento más las consideraciones vistas previamente se puede tener una idea clara de cuales son aquellos casos de prueba o funcionalidades a automatizar.

Cómo Comenzar

Luego de seleccionar un proyecto para un piloto, y seleccionar ciertos casos de prueba para automatizar, lo que recomendamos es comenzar por un subconjunto acotado de casos de prueba (no más de 10) y ponerlos a funcionar. Esto es: diseñarlos (en papel, planillas, etc.), automatizarlos (con GXtest Designer y Recorder), preparar ambiente y datos para poder probarlos, preparar la ejecución programada de estos casos (con GXtest Manager, haciendo que ejecuten todas las noches por ejemplo) y definiendo las metodologías para trabajar. Una vez que preparemos esto comenzaremos a ver los beneficios y a alimentar la máquina de pruebas automatizadas, haciéndola crecer cada vez más, obteniendo cada vez más beneficios.

Ver también

Se viene GXtest 1.1

2010-01-19T10:47:00.000-08:00

Como ya habrán leído por ahí, hace ya unos meses que se lanzó la primera versión comercial de GXtest (**). Hoy en día, nos estamos preparando para lanzar una nueva versión, poniendo a disposición más funcionalidades y mejoras.

Ejecución en Firefox

En un comienzo GXtest permitía grabar las pruebas y ejecutarlas en Internet Explorer. La ampliación en este sentido fue el haber agregado la posibilidad de ejecutar en Firefox. Entonces, las mismas pruebas las podremos ejecutar ahora en dos de los más famosos Navegadores. Estaremos trabajando en futuro para dar soporte para otros, como ser Google Chrome. También en este sentido será interesante dar la posibilidad de poder grabar las pruebas en otros Navegadores.

Integración con la BL de GeneXus X (o superior)

Si se desea automatizar pruebas sobre una aplicación es necesario brindarle a GXtest el acceso a la metadata de la KB de la aplicación. Si se trata de GeneXus 9 o inferior se puede utilizar GXpublic. También se puede utilizar el XPZ obtenido tras exportar la KB desde GeneXus, y en el caso de que estemos utilizando GeneXus X o superior era necesario hacer un export con una extensión específica que forma parte de la solución GXtest. El problema con esto es que era necesario instalar la extensión en GeneXus, entrar, abrir la aplicación, exportar generando así un archivo .GXT (similar a un XPZ), luego entrar en GXtest e indicar la ruta a este archivo. Esto cada vez que se quiera impactar los cambios del ambiente de desarrollo sobre el de testing. Por eso es que agregamos la opción de acceder a la KB a través de la BL (GeneXus Business Logic) cuando se trata de GeneXus X o superior. Esto brinda la misma comodidad para el usuario que cuando se trata de GeneXus 9 o inferior y selecciona usar acceso con GXpublic.

Organización en Folders

En un principio no se ve la necesidad, pero cuando uno comienza a automatizar pruebas y tiene cada vez más Test Cases automatizados se puede volver complejo administrarlos y organizarlos. Para ello ahora se puede trabajar en una estructura de Folders (directorios/carpetas) que nos permiten más facilidad para clasificar y localizar luego cada uno de nuestros Test Cases o Data Pools.

A futuro agregaremos la opción también de categorizar los artefactos de prueba, para poder manejar varios criterios de clasificación.

Mejoras de performance en la ejecución de pruebas

Se optimizó notoriamente la ejecución de las pruebas. Esto es muy importante para poder tener los resultados de grandes cantidades de pruebas en menor tiempo.

Gráficas para Resultados

Como dijo Scott Barber en un evento del CES una vez, "más vale números que letras, y más vale gráficas que números". Siempre que uno quiere analizar grandes cantidades de datos se simplifica mucho más pudiendo visualizarlos en forma gráfica, por este motivo se agregaron los primeros reportes gráficos en GXtest Manager (encargado de gestionar el repositorio de pruebas).

En Abstracta estamos muy contentos por los logros y el crecimiento que vemos que GXtest está alcanzando, y por el feedback positivo de los clientes que han confiado en este corto plazo de vida que tenemos. Gracias!

Estamos también pensando en definir un período de betatesting, ¿hay interesados?

(**) La misma es comercializada a través de Artech y su red de distribuidores en todo el mundo, o poniéndose en contacto con sales@genexus.com.

Automatizar el diseño de los casos de prueba

2010-01-04T11:28:00.000-08:00

Uno de los puntos fuertes que nos planteamos al comenzar con GXtest fue la generación de casos de prueba a partir de modelos. Hoy en día con GXtest se pueden expresar los casos de prueba como modelos pero no se puede generar automáticamente casos de prueba a partir de ellos.

La idea es que el tester pueda expresar el conocimiento que tiene sobre la realidad en un modelo para que luego a partir del mismo se generen los casos de prueba.

Les recomiendo que lean este artículo para entender mejor la motivación de este enfoque

Test Case Design: Manually or Automated?

Los dos modelos que siempre tuvimos en mente fueron el modelo de máquinas de estado y el modelo de casos de uso/diagrama de flujo.

¿Cómo podemos utilizar este enfoque con GXtest?

Una opción es utilizar (como dice en el artículo) una herramienta como Ms Visio para modelar nuestra realidad. Este modelado podría ser por ejemplo con un diagrama de flujo en donde en las distintas interacciones con el sistema se utilicen nombres de casos de prueba realizados en GXtest.

Luego que tenemos el modelo listo, este puede ser utilizado por una herramienta para generar distintos casos de pruebas, basándose en algoritmos conocidos de generación (realizando recorridas sobre el modelo). Estos nuevos casos de prueba generados, pueden estar en un formato "compatible" con GXtest.

Me parece que este es un mecanismo interesante para mejorar el testing en las empresas, mejorando de esta forma el alcance y cubrimiento de nuestras pruebas.

Algunas preguntas para quienes leen el blog, ¿Con que herramientas realizan el modelo de la realidad y/o de los requerimientos? ¿Ven factible aplicar algoritmos para la generación de casos de prueba a partir de estos modelos?

Seminario: Testing para Desarrolladores del CES

2009-12-07T12:30:00.000-08:00

El Centro de Ensayos de Software dictará un seminario de testing enfocado a desarrolladores.

Aquí está el resumen http://www.ces.com.uy/seminarioDesarrolladores2009/seminarioDesarrolladores.htm

aquí tienen más información sobre el contenido http://www.ces.com.uy/seminarioDesarrolladores2009/ContenidoSeminarioDesarrolladores.pdf

Está enfocado más que nada a programación Java, pero los conceptos son bien aplicables en cualquier ambiente de trabajo.

Nos vemos por ahí :)

Automatización de acciones de un tester: archivos de entrada

2009-12-03T03:20:00.000-08:00

En los casos de prueba se puede dar la necesidad de invocar distintos tipos de acciones. Si intentamos automatizar lo que hace un tester ahi tenemos un amplio abanico, pues un tester al probar una funcionalidad suele necesitar copiar archivos, disparar distintos programas, comandos, etc., incluso hasta verificar si le llega un e-mail generado por el sistema.

Nos tocó un caso en un cliente, el cual tiene un sistema que a partir de un archivo que se copia por FTP a un directorio hace que se generen tareas en un Flow, por lo que en ese caso de prueba automatizado se necesita copiar archivos en esa carpeta.

La primer solución que pensamos para poder hacer esto en GXtest fue generar un GeneXus Procedure que genere ese archivo en esa carpeta, ya que GXtest puede invocar procedimientos GeneXus desde los casos de prueba, por lo que podríamos automatizar este caso particular.

Una mejor solución nos la sugirió José y nos llevó a agregar un nuevo comando en GXtest el cual da mayor flexibilidad para otros tipos de situaciones. Un comando que pueda invocar un programa por línea de comandos. De esta forma en un caso de prueba automatizado se podría enviar el archivo por FTP tal como lo haría un tester o un usuario real.

Claro está, que esta solución resuelve otras situaciones como copiar archivos, ejecutar aplicaciones externas, etc.

¿Para que otras cosas se les ocurre que puede servir?¿Se les ocurre algo más que no esté quedando contemplado?

Automatización de "aplicaciones complejas"

2009-11-24T16:25:00.000-08:00

En un par de charlas nos han preguntado, "¿Qué pasa con GXtest si mi aplicación se comunica con otras aplicaciones legadas mediante mecanismos complejos?", "¿Qué pasa si consume servicios Web expuestos en otros servidores?" "¿Qué pasa si mi aplicación tiene lógica muy compleja?"

Imagen: a partir de un botón en la aplicación bajo pruebas se ejecuta una lógica compleja, hay comunicación con varias aplicaciones externas, y se dispara un cohete.

GXtest tiene como objetivo reproducir la interacción del usuario con el sistema, por lo tanto estas complejidades son indiferentes para GXtest. Una vez que el usuario presiona un botón, la lógica que se ejecuta a partir de esa acción pude ser simple o compleja, pero "a la vista" de GXtest es transparente (tan transparente como a la vista del usuario). Tal como se muestra en la imagen, no importa si se dispara un cohete o lo que sea, lo que "importa" para automatizar es la interfaz de usuario en este caso.

Ahora bien, hay veces que el caso de prueba requiere que se hagan otras acciones que no se pueden hacer en el navegador, por ejemplo consultar una base de datos, copiar archivos a un determinado lugar, etc. Para estas acciones GXtest (al igual que otras herramientas) brinda la posibilidad de realizarlas.

Bonus track:

El hecho de que una aplicación compleja no agregue dificultades a GXtest no implica que no agregue dificultades al momento de pensar y diseñar las pruebas automatizadas.

Dos de los temas más importantes que se pueden destacar son la preparación de los datos y la simulación de los servicios externos que se consumen. En particular en el segundo punto hay veces que es interesante que realmente el sistema bajo testing se "conecte" al servicio externo y hay otras veces que es preferible simular este servicio. El artefacto que simula el servicio externo generalmente se lo llama Mock Service.

En el caso de que ese servicio sea un web service les recomiendo la aplicación SoapUI que brinda una interfaz muy amigable para generar servicios Mock así como para testear servicios Web.

¿Qué otras herramientas utilizan para sus pruebas (automatizadas o no)? ¿qué cosas requieren sus casos de prueba (FTP, Web Services)?

GXtest por Uruguay y el mundo

2009-10-28T16:55:00.000-07:00

Con el fin de difundir GXtest, encaminamos una serie de presentaciones en distintos lugares. Aca les dejamos un resumen de las que ya ocurrieron y las que vienen...

México

Rodrigo Alvarez fue el primero (aparte de nosotros :P) en realizar una presentación de GXtest con demo incluída. Estuvo mostrando el producto a los distribuidores de ese país y vino con comentarios muy buenos.

Buenos Aires, Argentina

De la mano de Toolnology y Artech, presentamos el 21 y 22 de octubre GXtest en Buenos Aires. La verdad estuvo muy bueno ya que tuvimos la oportunidad de conocer mejor las inquietudes en el área de testing en el país vecino y nos fuimos muy contentos ya que la gran mayoría visualizaba a GXtest como una ayuda en su proceso de testing.

Montevideo, Uruguay

El 27 y 28 de octubre junto con Artech estuvimos presentando el producto acá en Montevideo. Asistieron una gran cantidad de empresas (según algún amigo de Artech eso fue porque en la invitación pusimos que había desayuno :P). Más allá de porque fue la gente, en general se mostraron muy interesados por el producto y con ganas de empezar a evaluarlo para ver como se adapta a sus realidades.

Chicago, Estados Unidos

El Fede estará mostrando el producto en el Genexus 5th USA Annual Event el 2 y 3 de Noviembre.

Chile

Ayer Rodrigo presentó GXtest en el Evento Chileno. Esperamos los comentarios del mismo...

Paraguay

Fabián estará viajando el próximo martes 3 a Asunción para presentar el producto en las instalaciones de SISA.

Brasil

Sao Paulo nos espera el 2 y 3 de diciembre para presentar GXtest a Corporativas y software houses.

Además el 17 y 18 de noviembre en el Latu estaremos brindando un curso de GXtest para que las empresas lo puedan conocer más en profundidad.

Abstracta en el XIX Encuentro Internacional GeneXus

2009-09-03T15:41:00.000-07:00

Estamos muy contentos de invitarlos al XIX Encuentro Internacional GeneXus!!

Como saben, este mes en el encuentro de usuarios liberamos la versión comercial de GXtest, y nos alegramos en invitarlos a todos al encuentro en general y a las instancias que estaremos participando en particular.

Abstracta estará participando en las siguientes instancias

GeneXus en el desarrollo, GXtest en el testing: presentaremos la primer versión comercial de GXtest.

Testing Automatizado: ¡Hagamos que las máquinas trabajen por nosotros!: estaremos compartiendo nuestra experiencia en automatización de pruebas funcionales, y todos los desafíos que involucra embarcarse en estas tareas.

Café con Testing Automatizado: junto al CES y todos los participantes estaremos charlando sobre el testing automatizado. La idea es tener un ámbito distendido en donde puedan discutirse temas relacionados al testing automatizado.

Los esperamos a todos en el XIX Encuentro Genexus!!

Inscribite en http://www.genexus.com/encuentro/

¿Quién crea los casos de prueba?

2009-08-31T08:44:00.000-07:00

Para seguir con la serie de articulos sobre preguntas del testing automatizado, es que aquí planteamos esta, ¿Quién es el que crea los casos de prueba?

Algunos casos de prueba los puede crear el desarrollador, otros los testers y otros los clientes.

Los casos de prueba pueden ser creados, ejecutados, aprovechados, por muchas personas dentro de la vida del software. Con esto me refiero a que se van a ver beneficiados desde los desarrolladores al construir el primer prototipo, hasta el último de la cadena de producción que es el usuario que va a utilizar el sistema.

Cada una de las personas que participan podrán tener distintos objetivos y desafíos, podrán obtener distintas ventajas o beneficios de la automatización de pruebas.

Desarrollador:

Seguramente un desarrollador que implemente el Objeto1 (transacción o WebPanel), o el Proc1, implementará pruebas que exploten a ese objeto en forma más unitaria, probando con casos bien concretos, viendo qué pasa con las distintas entradas.

Los casos de prueba serán cortos y generalmente no utilizarán otros objetos a menos que sea necesario.

Por lo general también sucede de que al ser la misma persona que desarrolla, las pruebas estarán pensadas con una lógica similar a la que se usó al desarrollar.

Tester:

El tester ya tendrá más vision global, vision de negocio, por lo que será capaz de probar las funcionalidades en un ciclo completo.

Los casos de prueba serán más largos y complicados, buscando las formas posibles de evidenciar las faltas más importantes de la aplicación.

Usuario:

El aporte más rico del usuario es que sabe priorizar mejor que nadie las funcionalidades críticas para su negocio, con la parametría propia de su realidad, y con el modo de uso que le da al sistema.

Los casos de prueba serán pensando en sus necesidades y no en las fortalezas o debilidades de la aplicación. Le interesa que funcione lo que a él le da más valor.

Como conclusión podemos decir que la mezcla de todas estas visiones es la que genera un verdadero mix saborizado de pruebas. Sería ideal contar con aportes desde todos estos lados a la batería de pruebas a ejecutar.

¿Quiénes hacen pruebas en sus organizaciones?

Cómo elegir cuando ejecutar los casos de prueba?

2009-08-11T06:00:00.000-07:00

Otra de las preguntas que surge al llevar a cabo un proyecto de automtización de pruebas es en qué momento ejecuto las pruebas?

Lo primero que uno piensa es tan frecuente como se pueda, sin embargo, los recursos son escasos y dependiendo de la cantidad de pruebas automatizadas el tiempo que se demore en ejecutar puede ser muy largo.

Generalmente se puede apuntar a tener algunos ambientes bien separados. A modo de ejemplo simple:

el de desarrollo (cada desarrollador)
el consolidado de desarrollo
el de testing (dentro del equipo de desarrollo)
el de pre-producción (testing dentro del cliente)
el de producción.

El conjunto de pruebas y la frecuencia de las mismas en cada uno de estos ambientes seguramente sea diferente.

En desarrollo se tiene la neceidad de mayor agilidad, ya que se van a querer correr con mucha frecuencia, imagino que después de cada cambio importante, antes de hacer un commit en el sistema "SVN" o "CVS" o equivalente.

Ahora para eso sería muy conveniente correr solamente las pruebas necesarias (mirar el post anterior). Estas pruebas tienen el fin de darle un feedback rápido al desarrollador.

Una vez que el desarrollador libera su módulo o cambios a la consolidación, se ejecutarían pruebas a modo de Pruebas de Integración. Acá lo ideal sería que corran en las noches así de mañana cuando llegan los desarrolladores tienen una lista de posibles asuntos a solucionar, y que tengan un feedback de los cambios que introdujeron ayer. Mientras menos tiempo pase más rápido lo van a solucionar. Esto permitiría no pasar a testing cosas que no funcionen. Serían como pruebas de humo en cierta forma.

Luego cuando se pasa la aplicación a testing, se debería correr un conjunto más grande de pruebas de regresión que intenten asegurar que los errores que se han reportado y se han marcado como solucionados no están presentes en esta nueva versión. Este conjunto de pruebas puede tardar más tiempo en correr. Estas pruebas no tienen porque ser periódicas sino que pueden adecuarse al cronograma del proyecto con las fechas previstas de liberación.

Cuando se llega a la versión entregable de la aplicación (aprobada por el equipo de testing), la misma se libera al cliente. Este por lo general la testea también en un ambiente de pre-producción, el cual debería ser totalmente simétrico en configuración al de producción (esta es la diferencia con el ambiente de testing del equipo de desarrollo). Aquí también aporta valor tener un conjunto de pruebas automatizadas.

Este conjunto de pruebas podría ser como mínimo el que se corrió en testing, e incluso se le podría entregar al cliente el conjunto de casos de prueba automatizados junto con la aplicación liberada, ya que le da mayor seguridad y confianza al cliente el saber que se testeó antes de su liberación.

Como manejan las pruebas hoy en día? que ambientes manejan?

Algunas de estas ideas aplican ya sea que se tengan pruebas automatizadas o no?

Cómo elegir qué ejecutar?

2009-08-07T10:52:00.000-07:00

Esto es un problema que se plantea al momento de tener muchos casos de prueba automatizados. Cambia la aplicación y tengo que decidir qué casos de prueba ejecutar.

Si tengo tiempo la respuesta es simple: TODOS. Esto me dará más garantías, y no me cuesta más que mandar a ejecutar una prueba.

Ahora, qué pasa si no tengo tiempo suficiente. Ahí es donde tengo que seleccionar los casos de prueba que me den mejor relación costo-beneficio, o sea, aquellos que verifiquen todo lo que pueda estar impactado por los nuevos cambios en la aplicación.

Cambiamos entonces a una nueva pregunta: ¿cómo saber qué casos de prueba verifican cosas sobre los nuevos cambios ingresados a la aplicación?

Este problema lo entendemos a dos niveles. Un primer nivel, y es el que parece más obvio, si cambian los objetos de interfaz de usuario los casos de prueba automatizados se verán impactados, y ahí se detecta fácilmente cuáles son los que tengo que volver a ejecutar.

Ahora, lo más desafiante es poder extender este análisis para que contemple también en base a cambios de la lógica.

Si tenemos la metadata suficiente para detectar esos cambios a nivel de lógica luego se puede a partir de esto ir subiendo hasta ver qué elementos de interfaz gráfica están involucrados en los cambios, y así descubrir los casos de prueba que me vale la pena volver a ejecutar, o al menos llegar a establecer cotas, dejando por fuera los que no tienen posibilidad de haber sido afectados.

Palabras tomadas de un colega:

La tendencia en integración continua es que la selección de Test Case sea guiada, ya que en aplicaciones grandes no daría el tiempo de horas máquina para simular de forma secuencial todos los TestCase automatizados.

Una propuesta de solución a este problema va a venir incluida en el nuevo Visual Studio 2010. En un componente llamado Test Impact, les dejo un par de links: link1 y link2. En pocas palabras lo que hacen es correr los casos de prueba fijándose el cubrimiento que los mismos tienen y luego en base a esto proponer qué casos de prueba ejecutar ante cada cambio. Ahora, ¿qué pasa con esto si no hay cambios en el código sino que el cambio está en el esquema de la BD o en los datos de la BD?

¿Cómo seleccionan los casos de prueba a ejecutar ante cada nueva release?

PIM y PSM en el Testing

2009-08-05T10:08:00.000-07:00

Estos días estuve leyendo el artículo de Bea (pueden encontrar una breve descripción en la página del CES (dentro de Proyectos de Investigación/Pruebas en Líneas de Producto de Software (ProTest)) , y ahí recordé algo que aplica a Genexus, que es lo de Platform Independient Model y Platform Specific Model.

O sea, en el mundo GeneXus, la KB sería el PIM y la aplicación generada el PSM.

En nuestro caso, vemos que GXtest es una herramienta que maneja modelos PIM, y tiene las ventajas típicas de estos modelos en comparación a las herramientas tradicionales que se acercan más a un PSM, pues van directo al HTML del Java generado, o del .Net generado.

Además fui a una charla de un amigo español (Dr. Ruiz) la cual me resutló muy interesante como para profundizar el tema.

Algo que nos preguntábamos es si en alguna forma GeneXus se puede definir como un Lenguaje especifico de Dominio? Cual sería el dominio en ese caso? Qué opinan?

Mantenimiento de Pruebas de distintas Versiones de la misma KB

2009-08-03T08:30:00.000-07:00

Supongamos que hoy tengo una versión de la aplicación Carrito.v.1. Todos los casos de prueba funcionan sobre esa versión. Tal vez esa versión de Carrito.v.1 está congelada e instalada en un par de clientes.

Ahora bien, supongamos también que sigo desarrollando y se produce una nueva versión que le llamaremos Carrito.v.2. Es probable que hayan cambiado algunas funcionalidades, se hayan agregado una nuevas, etc. Entonces es importante actualizar todos los casos de prueba (ya sean manuales o automáticos) para que se adapten a esta nueva versión.

Cómo manejan ustedes esto hoy en día? Una opción es tener dentro de la "línea base", con un tag del SVN o en algún lugar separado, no sólo las distintas versiones de la KB (u código), sino también las distintas versiones de los casos de prueba, no?

Luego cuando el cliente de Carrito.v.1 reporta un error hay que ir a arreglarlo a Carrito.v.1 y fijarse si ese bug aplica también a Carrito.v.2. Luego hay que correr los casos de prueba de regresión de ambas versiones. Y si luego tengo Carrito.v.N, cómo hago para correr los casos de prueba asociados a las N versiones??

Pensando en esta problemática GXtest ofrece hoy en día dos facilidades. Por un lado una funcionalidad para impactar los casos de pureba automatizados con la nueva versión de la aplicación (KB). Por otro lado lo que permite es duplicar todo un proyecto de pruebas (casos de prueba, datos de prueba, etc.) a modo de "Taggearlo" para que de esa manera pueda conservar los casos de prueba en distintas versiones del producto. Entonces se puede ejecutar pruebas actualizadas sobre la última versión del producto, pero interesa que si se hacen cambios sobre la versión del cliente aún se puedan correr las pruebas de regresión sobre esa versión previa congelada.

Resumiendo. La infraestructura final de pruebas contará con N instancias de la aplicación bajo prueba, una para cada versión que interese correr pruebas de regresión. Por otro lado tendremos N proyectos de prueba en GXtest con los distintos casos de prueba, cada uno correspondiéndose con las versiones de la aplicación.

Se Busca una idea original!!

2009-07-28T05:48:00.000-07:00

Estamos buscando una idea original para promocionar GXtest en el evento GeneXus. Por ese motivo y con plena confianza en quienes leen este blog, es que lanzamos el concurso de "Ideas Originales para Promocionar GXtest en el Evento GeneXus".

Cualquier lector en cualquier parte del mundo puede participar del concurso dejando su comentario en este post (si Simon, estamos pensando en vos también que sabemos que te sobran ideas originales :P).

El objetivo de la idea original debe ser lograr que la gente conozca GXtest y sepa para qué los puede ayudar. Cualquier tipo de juego, concurso o lo que se les ocurra sirve.

La semana pasada surgió una idea muy buena, pero por lástima solamente a mi me pareció grandiosa. La idea consiste en mandar a hacer unos matamoscas inflables (con el logo de GXtest). La idea entonces era regalar estos matamoscas y que la gente luego pueda matar bichos (Bugs) con el super matamoscas.

Luego se le sumaron otros complementos a la idea como por ejemplo regalar también punteros láser en forma de bicho. Uno de las objeciones a la brillante idea es que la gente va a ir a otras charlas y va a ocasionar disturbios para los cuales se presta tanto el puntero láser como el matamoscas :P

Se agradecen todas las colaboraciones!!

PD: las mejores 5 ideas llevarán como premio una mención y agradecimiento especial en el blog de Abstracta :D

DataPools

2009-07-27T04:30:00.000-07:00

Los DataPools (en donde se guardan los datos de entrada de los casos de prueba) le dan un gran poder a los casos de prueba, pero cuando empezamos a construir casos de pruebas relativamente grandes nos hace falta ese "poder" que sentimos los desarrolladores al escribir sentencias tales como JOIN (en SQL), foreach (en Genexus) y otros, para manipular datos en estructuras tabulares.

En un lenguaje "gráfico", o en un modelo, es más difícil expresar este tipo de realciones en forma simple para el usuario. De todos modos la necesidad existe, y muchas veces queremos "mantener el contexto" del conjunto de datos que estamos utilizando en cada ejecución.

Para esto construimos un mecanismo que le llamamos "DataPools estructurados".

Aquí están las diapositivas que intentan explicar el funcionamiento de DataPools:

GXtest - DataPools Estructurados

View more presentations from guest7f6eaae.

Necesitábamos brindar un mecanismo lo más intuitivo para el tester. En general, cuando un tester construye un caso de prueba, piensa por un lado las acciones que se tienen que ejecutar en la aplicación, y por otro lado varios conjuntos de datos para utilizar en esas acciones.

Por ejemplo, para un caso de prueba de "alta de países", nos puede interesar primero probar con el conjunto de datos 1, que referido a Uruguay, con los departamenteos Salto, Paysandú y Montevideo, etc., y luego el conjunto de datos 2 para Argentina, con las provincias de Río Negro, Corrientes y Santa Fe.

Eso es lo que intenta expresar cada "Set Id": todos los datos, en los distintos datapools, se agrupan por el identificador de conjunto de dato.
Es similar a cuando uno piensa los datos de prueba para cada caso. Se agrupan, se definen e identifican.

¿Se entendió la idea? Se aceptan sugerencias!!

Composición de Comandos

2009-07-24T06:10:00.000-07:00

El amigo Marcos nos sugirió una idea que está muy interesante: dar la posibilidad al usuario de componer comandos.

Como sería esto? Por ejemplo si siempre para hacer login en mi aplicación ingreso dos campos (usuario y password) y luego presiono el boton de ingresar, sería deseable poder llamarle a esas tres acciones Login y utilizarlas donde quiera como un comando común.

Hoy en día, si quiero hacer esto, lo más práctico es hacer un caso de prueba similar al de la figura, llamado login, que haga estas tres acciones y luego incluirlo en el caso de prueba que desee (en la imagen las acciones estarían asociadas a la arista login).

La ventaja que tiene poder componer comandos (aparte de la puerta que abre para crear cosas bastante sofisticadas) es la posibilidad de dejar más compactos los casos de prueba sin necesidad de tener que incluir casos de prueba para representar acciones comunes en la aplicación.

Formalizando un poco el planteo, el requerimiento sería poder definir nuevos comandos (esto implica nombre y tipo de comando -evento, accion o validación-) el cual recibe una lista de N parámetros, los cuales se mapean a una lista de M comandos. Los parametros de los M comandos podrán ser parte de los N de entrada o simplemente tener valores fijos.

Que les parece la idea? A nosotros nos pareció muy interesante y ya la anotmos en la wiki de Abstracta para implementarla más adelante.

Se aceptan sugerencias.

Nuevo socio de la CUTI: Abstracta

2009-07-23T07:10:00.000-07:00

Abstracta es ahora socio de la CUTI

Nos hicimos socios aprovechando un nuevo programa que tiene la CUTI para emprendimientos nuevos. La CUTI en conjunto con varios actores de gran peso están apoyando de diversas maneras los emprendimientos en Uruguay. Esto es muy bueno para todos, no solo para los emprendedores sino también para todo Uruguay. Esperemos en unos años ver el fruto de toda esta movida.

La CUTI además de brindar una lista extensa de servicios a los socios, nos permite contar con un apoyo importante a la hora de salir a vender nuestro producto.

Otros beneficios importantes son: el pertenecer al programa Bizpark de Microsoft, del que hablamos hace un tiempo en este post, y también FengOffice gratis por 3 años!

Habrá que sacarle jugo a todas estas cosas!!

Nuevas Oficinas (II)

2009-07-13T21:00:00.000-07:00

El título de este post no significa que ya nos mudamos de nuevo! sino que tenemos noticias con respecto a lo que propusimos en "Nuevas Oficinas". A partir del mes de julio tenemos roomates.

Se trata de algo que no nos imaginamos en un comienzo. Nosotros buscábamos una pequeña empresa que esté en la misma que nosotros. No es exactamente así, los que se vienieron al apto son tres freelancers.

Bienvenidos Nacho, Gerva y Nando!

De todos modos estamos con la ambisión de conseguir algún otro interesado, ... el apto es grande y se presta para más!

De paso aprovechamos y nos pusimos a pintar :)

Test cases resistentes a parametrizaciones

2009-07-07T14:46:00.000-07:00

Problema:

Tengo un Test Case para el caso de uso de "Alta de producto". Este caso de prueba debe funcionar y testear correctamente el caso de uso para cada una de las parametrizaciones deseadas.

Esto significa, hacer un Test Case que sea resistente a las parametrizaciones.

En las aplicaciones desarrolladas con GeneXus es muy típico que se permitan muchos tipos de parametrizaciones, y esto trae asociado ciertas complicaciones: las respuestas esperadas válidas varían según cómo esté parametrizada la aplicación, incluso el flujo a recorrer. Esto implica que al modelar un Test Case se tengan que agregar bifurcaciones en el flujo, las cuales se guíen por decisiones basadas en los valores de estas parametrizaciones. El tema es que hay que ver cómo averiguar (dentro del Test Case) cuáles son los valores de esas parametrizaciones al momento de estar ejecutando.

¿Cómo hacer Test Cases soportando parametrizaciones? ¿cómo tomar estos valores de parametría al momento de la ejecución, sin tener que indicárselos manualmente? Voy a sugerir algunas soluciones, alguna es aplicable en distintas herramientas, otra (la más eficiente) es más específica para GXtest, aunque se puede hacer algo similar en otros ambientes también.

El objetivo es tomar los valores de los parámetros que afectan al caso de uso.

Solución #1: hacer un Test Case por cada una de las combinaciones de parámetros. Esto evidentemente tiene la desventaja de que se duplica trabajo y se aumentan los puntos de falla.

Solución #2: diseño Test Cases auxiliares que sirvan para consultar esos parámetros y estos se cargan en variables (o lo que maneje la herramienta), y entonces de esa forma en el Test Case de "Alta producto" ejecuto primero los Test Cases auxiliares que consultan parámetros, y luego se hacen las decisiones en base a las variables cargadas. La principal desventaja es que esto hace que se vaya por muchas pantallas innecesariamente, consumiendo más tiempo de ejecución para cada Test Case que requiera consultar parámetros. Además, es necesario automatizar Test Cases que tal vez no son incluidos en el conjunto de pruebas de regresión, o sea, que no estaban planeados en la automatización.

Otra desventaja es que si llega a fallar uno de los Test Cases que toman parámetros, entonces no se podrá ejecutar el Test Case principal.

Solución #3: la que creemos más eficiente es con ProcGX, los cuales se desarrollen específicamente para devolver los valores de los parámetros que se necesitan. Desde GXtest es posible cargar en variables el resultado de la invocación a un ProcGX y luego tomar bifurcaciones en base a estas variables (pero esto es útil as well en otras herramientas en las que se pueda invocar a Web Services). La ventaja es que en tiempo de ejecución es más eficiente, así como en tiempo de desarrollo. La desventaja es que el tester "depende" del desarrollador para esta tarea.

Un comentario al margen es que las parametrizaciones en los casos de prueba es un tema ligado con a Líneas de productos de lo cual hemos hablado en el blog. Ese enfoque nos podría permitir derivar los casos de prueba a partir de la línea de producto específica que tengamos, permitiendo de ese modo no solo crear sistemas más sencillos y específicos sino también casos de prueba más prolijos.

¿Alguien más se ha chocado con este problema? ¿alguna otra solución que se les ocurra?

Testing is not a phase!

2009-06-22T15:43:00.000-07:00

Cómo aprendemos sobre testing? cómo usamos el testing en nuestros desarrollos?

Estará eso vinculado?

En nuestro caso en la facultad vivimos un proceso un poco estricto, que se refleja bastante en la industria:

primero matemáticas y materias formativas, nos ayudan a crear el pensamiento abstracto y lógico

programación básica, estructurada y usando constructores fundamentales

programación con tipos abstractos de datos

programación con algoritmos sobre estructuras de datos

programación orientada a objetos (en c++)

un lenguaje con más abstracción (java)

mechado por ahí tenemos sistemas operativos, arquitectura, y otras yerbas

luego, un proceso pesado como lo es el RUP, poniéndolo en práctica en un grupo de 12 a 14 personas. Recién en estas materias se ve algo de testing.

para 4to o 5to año hay una electiva (en la que participamos como docentes Diego Vallespir, Mónica W. del CES, Matías y yo) llamada TVS.

Qué nos deja esto? que el Testing es algo que queda para el final, ... oh vaya casualidad! no es esto lo que pasa generalmente en el desarrollo? Por eso se habla tanto de la "etapa de testing", cuando en realidad debería ir más de la mano con el desarrollo en sí.

Hace poco participé de una reunión en facultad (con integrantes del CES también) en la que se demostraba el interés por cambiar esto, y comenzar el cambio desde la enseñanza, mostrando que el testing no es una etapa, no es algo que se hace al final, sino que es una tarea que acompaña y retroalmienta al desarrollo desde un principio.

A nosotros nos interesó hablarles de esto para contarles de una funcionalidad de GXtest en realidad, que tiene como objetivo en gran medida permitir que las pruebas automatizadas se lleven en conjunto con el desarrollo. Si bien esto no es lo único importante para acompañar el desarrollo con el testing, es nuestro granito de arena.

Ya por usar Genexus tenemos la posibilidad de ir probando nuestros "prototipos", que en realidad son la aplicación en sus orígenes. La idea con Genexus (tal como lo dicen los manuales) es ir desarrollando una serie de prototipos que van creciendo y tomando forma hasta tener la aplicación. La gran ventaja es que podemos testear desde los primeros días de desarrollo.

Con GXtest pretendemos que sea posible automatizar las pruebas desde lo antes posible.

Qué problemas pueden ocurrir con esto? los obvios, de que automaticemos pruebas, y al continuar el desarrollo de la aplicación nuestras pruebas se rompan por los propios cambios introducidos al evolucionar el desarrollo.

Ya que GXtest está "atado" o "enganchado" a la KB de Genexus, es posible tener pruebas automatizadas para una versión de la KB y que al momento en que se haga un nuevo deploy en el ambiente de testing, también se actualice la KB que maneja GXtest en sus TestCases, para que estos se ajusten a los cambios ingresados. El objetivo es que esta tarea de "impactar la nueva KB sobre GXtest" sea lo más automática posible, aunque para algunos casos particulares requerirá de la asistencia del usuario.

Ejemplo

rename de objetos referenciados en TestCases

rename de controles referenciados en TestCases

delete de objetos o controles referenciados en TestCases

nuevos objetos o controles, cambios en objetos no utilizados

También entra en juego el buen criterio para la planificación de la automatización de cada prueba. Consideramos que está bueno automatizar e incluir lo antes posible en el set de pruebas de regresión automatizadas una funcionalidad, pero también hay que ver que esté estable enough como para que no me implique tanto trabajo hacer el mantenimiento a ese TestCase.

Esta necesidad de planificación la contamos también desde la experiencia por las pruebas automatizadas que armamos para GXtest en su desarrollo.

Es importante por comenzar al menos por un conjunto simple de Test Cases, pero comenzar temprano! Luego que tenemos la "infraestructura de pruebas" aceitada, es más fácil agregar nuevas pruebas al conjunto de pruebas de regresión. En cambio si esperamos para tener un conjunto más amplio de funcionalidades para automatizar, demoraremos más en obtener los beneficios.

De lo que estamos seguros también es que no consideramos al testing como una fase, o como algo que hay que dejar para el final, ... tal vez eso por la experiencia que nos ha dado trabajar en el CES y la preocupación por la calidad del producto que nos ha inculcado esa "escuela" que tuvimos.

Gracias David por el link a la revista M&T de donde nos inspiramos para este post!

GXtest Avant Premiere - en el GUG

2009-06-16T13:53:00.000-07:00

El próximo sábado 20 de junio a las 11 horas en la Pizzería armenia Nairi (Agraciada 3560 y Buschental) tendremos el agrado de presentar en el primer GUG Montevideo de este año.

El título de la charla es "GXtest Avant Premiere", y ya que se acerca la fecha de su liberación, la idea es mostrar los avances en el desarrollo de GXtest y las funcionalidades que tendrá la primer versión que estará disponible para el próximo evento GeneXus.

Habrán otras charlas muy interesantes las cuales se listan en el blog del Grupo.

Esperamos verlos por ahi.

Qué bueno que vamos de nuevo con los lehmeyunes de Gustavo!

Interoperabilidad de GXtest (II)

2009-06-09T13:02:00.000-07:00

Como mencionamos en un post anterior, es de interés del equipo que GXtest pueda interoperar de la mejor manera posible con otras aplicaciones.

Una de las formas de interoperar es dar la posibilidad de crear casos de prueba con una herramienta externa, ya sea porque se quieren crear de manera automática en base a metadata de la aplicación, en base a un modelo de la aplicación, o porque simplemente se desean escribir a mano los casos de prueba. Sobre los motivos ya hablamos mejor en el post anterior, así que en este queríamos mostrarles algo más concreto.

En particular en esta página de la wiki de Abstracta van a poder encontrar información sobre el XML que se debe generar para crear casos de prueba para que luego se puedan importar en GXtest.

Se buscó diseñar un XML bien sencillo para poder disminuir la dificultad de realizar esta tarea.

Si bien es una versión inicial, ya da la posibilidad de ir "abriendo la cancha" para quien quiera probar sus ideas de generación de Casos de Prueba. Seguramente a medida que algunas personas comiencen a usar este mecanismo se irá puliendo el mismo para hacerlo más sencillo para quien desarrolle la aplicación de generación de casos de prueba.

Como siempre todas las sugrencias y aportes son bienvenidos!!!

Pruebas de Regresión (II)

2009-06-05T17:09:00.000-07:00

En un post anterior ya hablamos algo del concepto de pruebas de regresión. Ahora, ¿qué es lo que se busca hacer al automatizar este tipo de pruebas? (más allá de los detalles sobre el origen de su nombre).

Algunas ideas tomadas de distintas charlas con varias personas:

Desarrollador:

Quiero hacer cambios sobre la aplicación, pero me da miedo de romper otras cosas. Ahora, testearlas todas de nuevo me da mucho trabajo. Ejecutar pruebas automatizadas me da un poco de tranquilidad de que con los cambios que hago las cosas que tengo automatizadas siguen funcionando.

Tester

Mientras automatizo voy viendo que la aplicación funciona como es deseado, y luego se que lo que tengo automatizado ya está probado, dándome lugar a dedicar mi tiempo a otras pruebas, con lo cual puedo garantizar más calidad del producto.

Desarrollador

Hay veces que no innovo por miedo a romper, principalmente cuando tengo sistemas muy grandes, que cambios en un módulo pueden afectar a muchas funcionalidades.

Usuario

Cuando me dan una nueva versión de la aplicación no hay nada peor que encontrar que lo que ya andaba dejó de funcionar. Si el error es sobre algo nuevo, se entiende, pero que sea sobre algo que ya se suponía que andaba cuesta más. Las pruebas de regresión me pueden ayudar a que esto no pase.

A ustedes: ¿para qué otras cosas les parece que pueden servir las pruebas de regresión?

Las pruebas de regresión: ¿hay que automatizarlas si o si? ¿O se pueden hacer total o parcialmente de manera manual?

Curso de Introducción al Testing Funcional

2009-05-19T08:54:00.000-07:00

El testing es un área que está tomando cada día más fuerza, incluso en Uruguay.

Pueden verse cada vez más empresas que brindan servicios de testing, o en nuestro caso, vamos a ser una empresa que brinde productos de testing. Matías y yo en particular comenzamos trabajando en el área de testing en el CES (Centro de Ensayos de Software) y en estos cuatro años hemos notado la diferencia (evolución) en el mercado de cómo cada vez la gente se preocupa más por estos temas, y por suerte, cómo son cáda vez más los que intentan hacer mejor las cosas.

En particular, esta vez les queremos compartir la noticia sobre un curso, el cual está en el marco de algo que la CUTI le llama "Hacé Clic". Se trata de distintos cursos virtuales que parecen estar destinados preferentemente a gente joven como para que ingresen en el mercado laboral de TI.

Por lo que vi hay muchos cursos. Para seguir con el tema inicial, les queríamos recomendar uno que se llama Introducción al Testing Funcional el cual está armado por el CES, el cual es el referente en el tema en Uruguay.

La página muestra lo interesante de la iniciativa. También se pueden ver una serie de charlas que se estarán dando en liceos de todo el país.

Realmente está muy buena la iniciativa, esperemos les vaya muy bien, y se logre generar una masa crítica de gente capacitada como para darle más empuje al Software uruguayo, y si es con calidad, mejor!

Este tipo de cursos que está brindando la CUTI, me hace recuerdar una conversación que tuve una vez con un antiguo jefe en el CES, en donde me decía que es el colmo que hayan ingenieros que trabajan de programadores. Qué necesidad de hacer una carrera tan larga y compleja para poder trabajar como desarrollador. Además, se necesita también gente con conocimientos técnicos, más concretos. Mucha gente intenta y no triunfa, haciendo que la facultad sea en cierta forma ineficiente en su fin, el cual es formar ingenieros.
Este tipo de cursos puede ayudar a formar más gente en el área y que cada uno pueda estar más a gusto con su trabajo. A ustedes que les parece?

Conferencia "Innovación, creatividad y emprendedurismo" - Eduardo Kastika

2009-05-17T16:07:00.000-07:00

Acá les dejamos una conferencia más sobre temas de interés para emprendedores.

Es la segunda que aparece en la lista de esta página.

De paso revisen el resto de la lista que pueden haber más cosas que les resulten de interés.

1era convocatoria 2009: Emprendedores Dinámicos de la Facultad de Ingeniería

2009-05-13T16:01:00.000-07:00

Nos llegó un mail en donde se difundía la noticia. Es un poco sobre la fecha, pero como tenemos también el propósito de transmitir todo lo que apoye al emprendedurismo, aquí les dejamos el link.
Además, la Fundación Ricaldoni nos ha apoyado ya desde el comienzo de nuestro emprendimiento a través del EBT (Emprendimiento de Bases Tecnológicas) hasta el día de hoy tutoreándonos en el proyecto con la ANII (Agencia Nacional de Investigación e Innovación).

El mail decía lo siguiente:

Les recordamos que el viernes 15 de mayo de 2009 a las 13 horas vence la primera convocatoria 2009 del proyecto "Emprendedores Dinámicos de la Facultad de Ingeniería", realizado por la Fundación Julio Ricaldoni con el apoyo del Programa Emprender*.

El objetivo del proyecto es apoyar la creación de emprendimientos dinámicos de base tecnológica a través del respaldo del desarrollo de prototipos y/o ensayos relacionados principalmente con proyectos de la Facultad de Ingeniería de la Universidad de la República.

La Fundación Ricaldoni brindará a los proyectos seleccionados hasta US$ 2.500 en adquisición de bienes y/o servicios para el desarrollo del prototipo y/o ensayo, así como también apoyo técnico de un tutor especialista en el área del conocimiento relevante y capacitación en cursos adaptados a las necesidades de cada emprendimiento.

Las bases se pueden consultar en www.ricaldoni.org.uy/emprender.htm

Interoperabilidad de GXtest

2009-05-11T12:41:00.000-07:00

En el post anterior, hablabamos de la extensibilidad en GXtest, hoy en este caso nos interesa hablar sobre la interoperabilidad.

GXtest nos permite crear casos de prueba utilizando un editor gráfico de casos de prueba bastante amigable. Sin embargo, hay veces que es interesante hacer un programa que genere los casos de prueba de manera automática, de acuerdo a algún modelo o especificación de alto nivel.

Un ejemplo de esto puede ser el querer generar casos de prueba para un pattern determinado. Supongamos que queremos testear que el pattern WorkWith haya hecho las cosas bien para nuestra aplicación. En ese caso, los casos de prueba básicos sobre el WorkWith se podrían llegar a crear de manera automática y luego ser ejecutados por GXtest.

Para poder brindar esto, necesitamos tener una especificación clara (utilizando en parte un XSD) de cómo debe ser un documento XML que describa un caso de prueba en GXtest. De esta manera, fácilmente un programa puede generar casos de prueba que luego puedan ser importados y ejecutados en GXtest.

Esto da un gran potencial para la generación de casos de pruebas basados en modelos específicos para cada realidad.

Por otro lado, a mediano plazo pensamos integrar GXtest al IDE de GeneXus, lo que permitirá desarrollar otros plugins de GeneXus que utilicen servicios expuestos por GXtest.

Por último (y dentro de las funcionalidades que va a presentar GXtest Server) se va a permitir ejecutar casos de prueba o suites de casos de prueba definidos en GXtest desde afuera del mismo.

¿Que otros mecanismos les parecen interesantes?

Extensibilidad de GXtest

2009-05-03T09:06:00.000-07:00

Puntos muy importantes en una herramienta son la posibilidad de extender sus funcionalidades y la posibilidad de interoperar con sus componentes . Esto posibilita a los usuarios agregar nuevas funcionalidades o simplemente contemplar particularidades específicas de cada realidad.

GXtest permite hoy en día dos mecanismos de extensión, uno es agregando Custom Commands y otro es por medio de invocaciones a procedimientos GeneXus, para agregar validaciones y/o acciones sobre la aplicación bajo prueba.

GXtest le llama comandos a la forma de describir las acciones que un usuario puede realizar en el navegador. Existen entonces una serie de comandos que permiten describir (prácticamente) todas las acciones que el usuario puede realizar con una aplicación GeneXus.

Sin embargo hay veces que se desarrollan algunas secciones de la aplicación fuera de GeneXus, agregando algún javascript particular o algo similar. En esas situaciones puede ser que los comandos estándar no sirvan, y haya que desarrollar un Custom Command. Estos se dan de alta en GXtest ingresando el nombre que se le quiere dar, el tipo (acción, evento o validación), una descripción para los parámetros y el código javascript que implemente la acción del usuario. Luego este comando aparece listado como si fuera un comando estándar (el usuario no se da cuenta entre un comando estandar y uno desarrollado a través de este mecanismo).

Otro mecanismo es la posiblidad de agregar invocaciones a procedimientos GeneXus. Por ejemplo si se quiere validar algún estado de la aplicación a nivel de los datos luego de una serie de acciones interactivas, lo mejor es agregar un procedimiento GeneXus que se le pasen los parámetros necesarios (por ejemplo, nro de cliente, nro de factura, etc) y que devuelva si el estado es correcto o no. También se pueden utilizar para cargar datos que se van a suministrar como entrada en el caso de prueba.

Otra posibilidad que brindan estos proc es para usarlos como funciones que son interesantes de tener en una herramienta de prueba, como por ejemplo generar un número randómico, generar un string randómico, concatenar string, etc. Si algún procesamiento no se puede realizar por medio de GXtest, se puede implementar un proc GX que solucione esa feature.

Para poder realizar una invocación a un procedimiento GeneXus, el mismo debe estar accesible vía WebServices desde la máquina que corre GXtest. Para dar de alta un procedimiento se ingresa el nombre, tipo (acción o validación), descripción y url al WSDL (esto permite leer los parámetros de entrada y salida del procedimiento). Luego que se da de alta queda accesible de manera transparente (al igual que los custom commands) para el usuario.

En el próximo post hablaremos de la interoperabilidad, intentaremos abrir la posibilidad de generar casos de prueba desde "afuera", o exponer servicios en el IDE de GeneXus.

¿Que otros mecanismos les parece interesante de contemplar?

El Personal en TI

2009-04-20T05:54:00.000-07:00

Simon, me pasó este link en donde se armó una discusión muy interesante sobre el personal en TI.

Hay muchas de las cosas que se mencionan en los comentarios que me hacen pensar en los lugares que he trabajado, en los que aún trabajo y sobre todo en la empresa que estamos forjando (Abstracta).

La discusión en si está planteada por el lado de cuales son los perfiles más dificiles de recultar y los costos que cada uno implica, sin embargo lo que me pareció más interesante fue el punto de vista de que lo más importante no es como recultar sino como generar elementos valiosos dentro de la empresa, que luego hagan que la gente te elija a vos como empresa y sobre todo que la gente quiera seguir trabajando en tu empresa.

También coincido con lo que se menciona de que ha medida que vas conociendo el ambiente de la informática sabés en que empresa está bueno trabajar y en cual no, eso acá en Uruguay que somos muy chicos es aún más notorio.

Estoy convencido que el personal en la empresa es lo más importante y que, el cuidado que se tengan con todos los múltiples asuntos que involucra, son claves en el exito de la empresa.

Hace unos meses Gustavo Carriquiri posteó sobre el tema de la importancia del Capital Humano, basado en una interesante entrevista a Luis de Lezema.

He tenido la suerte de conocer por dentro varias empresas (ya que me ha tocado trabajar en clientes por períodos de algunos meses) y es increíble como en poco tiempo te das cuenta qué tan a gusto está la gente con la empresa y que nivel de compromiso se tiene con los objetivos empresariales.

Nosotros estamos recién arrancando y por ese motivo es un desafío aún mayor, ya que a diferencia de una empresa grande, los impactos que tiene que se vaya alguien de la empresa o que trabaje sin ganas son mucho mayores.

Este mes se nos unió a Abstracta, Sebastían Grattarola.

Sebastían es un excelente profesional con el cual hemos tenido la posiblidad todos nosotros de compartir trabajo e incluso estudio. Creemos que nos vamos a integrar muy bien como grupo y que va a contribuir de gran manera en el fortalecimiento de Abstracta.

Bienvenido Seba!!!

Nuevas oficinas

2009-04-06T13:56:00.000-07:00

Abstracta se mudó de oficina. O sea, tenemos oficina.

Estamos en un apartamento frente a la Facultad de Ingeniería, en el edificio Torre Patria, piso 13 (hermosa vista). Lo positivo de la ubicación está más que nada en el hecho de estar cerca de la facultad, pensando en contratar estudiantes, como para que les sea más facil la conmutación entre estudio y trabajo.

Acá les dejamos la vista en Google Maps

Una idea que venimos carburando hace mucho es la de compartir el lugar con otra empresa de características similares a las nuestras. Por ahora somos pocos, gente con ganas de crecer y seguir adelante, trabajando en un ámbito de amistad, y disfrutando de lo que hacemos.

Esta idea trae muchas ventajas. Cada empresa trabajando en lo suyo, pero compartiendo conocimiento, cada cual con su expertise, y a su vez teniendo la posibilidad de aprovechar la expertise de los demás (o al menos, los mates de la tarde ... jeje).

Es por esto que estamos en búsqueda de un roommate (¿?)... algo así como una empresa pequeña que quiera compartir el lugar físico, generar una sinergia de equipo ...

compartir desde la experiencia hasta los gastos e infraestructura....

esa es la propuesta.

Esperamos recibir interés por este "llamado" (contacto@abstracta.com.uy)

Acá les dejo el link a las fotos del sábado pasado, en donde hicimos lo que le llamamos La Oficianilización de Torre Patria, jeje, lo intentamos dejar con más facha de office :-)

(agradecimientos a La Flaca -esposa del Melli- quien nos dio una mano en esas tareas)

Update: Nuevas fotos en http://www.facebook.com/album.php?aid=72127&id=671387808&l=aead9f7349

Google Ventures

2009-03-31T13:07:00.000-07:00

Viendo como se movieron compañías como Motorola o IBM, creo que esto se estaba haciendo esperar mucho, a pesar de la primera aproximación de Google en Google Gadget Ventures

¿Quién mejor que Google para promocionar tu startup?

¿Qué tal si Google ve con buenos ojos tu idea y te financia? Dependiendo del startup, puede sonar muy alentador.

El nuevo sector de Google llamado Google Ventures, apostará a financiar startups relacionadas con la tecnología, en sectores como software, hardware, biotecnología y medicina.

Inicialmente invertirá 100 millones de dólares, financiando a cada emprendimiento desde un capital semilla, hasta "unas decenas de millones de dólares", dependiendo de la etapa y necesidades del mismo.

Leyendo las FAQs, Google no pretende ser el único inversor del emprendimiento y tampoco asegura adquirir tu firma (tampoco lo descarta), "es una inversión a largo plazo".

Para ser considerado hay que mandar un mail a ventures@google.com .

Wait! No más de 20 ppts!

Fuente: http://googleblog.blogspot.com/2009/03/googles-newest-venture.html

Testing Integrado al Desarrollo

2009-03-23T10:08:00.000-07:00

Algo interesante que tiene el Visual Studio 2008 que lo estamos explotando en la construcción de GXtest Client son los componentes específicos para testing, a nivel de desarrollador.

Si se fijan hay un menú llamado Test, en el cual uno puede crear sus Test (en nuestra jerga Test Cases), y sus Ordered Test (volviendo a nuestra jerga, Test Suites que son conjuntos de Test Cases). Además, hay un Unit Test Wizard que crea un Test Case a partir de una clase a probar, el cual nos mejora mucho el rendimiento al programar pruebas.

Este Wizard genera automáticamente mucho código que es siempre igual. Lo único que uno debe hacer es poner los datos de entrada y los de salida esperados (al menos para comenzar con pruebas simples).

Hace un tiempo probamos con NUnit. Al comienzo nos complicamos con algún problema, dado que a los proyectos del tipo Librería le tenías que decir que eran del tipo Console Application y asociarles como ejecutable el NUnit --era medio tranza--

Lo que no llegué a probar son cosas como NUnitAddin para tener el NUnit integrado al Visual Studio. De todos modos, el punto no está en qué tan bueno es NUnit o no, o las diferencias entre NUnit y el componente para testing que trae integrado el VS.

Hasta acá comentarios que aportan en el desarrollo de soluciones con VS. Ahora, todos los de la comunidad tienden siempre a pensar en soluciones Genexus, y en nuestro caso, cómo llevar estas soluciones que tiene un desarrollador C# en el testing, a un desarrollador Genexus??

Lo podemos ver por dos caminos. Uno es GXunit, el cual es un proyecto que ya tiene vida, y que tarde o temprano será culminado, y al cual esperamos poder dar nuestros aportes también. Esto es lo que más se asemeja con lo que estábamos hablando.

Por otro lado, podemos hablar de algo que José siempre nos insiste, integrar el GXtest Client al IDE de Genexus, para que de esa forma el desarrollador pueda tener sus pruebas automatizadas en el mismo IDE. Las pruebas que se automatizan con GXtest Client son pruebas a nivel de la interfaz gráfica (esto puede ayudar para hacer pruebas unitarias) pero el modelo propuesto está pensado para pruebas de sistema en las cuales se integran varios objetos GeneXus. Si nuestra unidad en GeneXus es un solo objeto (ya sea WebPanel o Transaction) los modelos en GXtest nos quedarían bastante particulares. Otra opción es permitir especificar los casos de prueba unitarios con un lenguaje de programación que tenga la misma expresividad que el lenguaje gráfico para permitir al desarrollador tener más flexibilidad a la hora de escribir sus casos de prueba.

Qué pasa con esto? GXtest en principio no es para que sea usado por los desarrolladores sino por los testers. Un argumento de esto es que no queríamos obligar a cada tester a tener una licencia de Genexus para usar GXtest. Por este motivo tal vez sería necesario tener dos versiones de GXtest Client, una liviana para integrar con Genexus, y otra que es la que estamos construyendo, independiente del IDE de Genexus y con todas las funcionalidades que necesita un tester.

Tener dos versiones de la interfaz gráfica sería muy costoso, por lo que hay una idea/posibilidad que resulta muy interesante:

Genexus tal vez puede presentar una posibilidad con su IDE tal como la que ofrece Visual Studio (Visual Studio Shell). Uno puede usar el IDE y el núcleo para desarrollar una herramienta y esto es Royalty Free, o sea, no hay que pagar extra por usar el Shell. Se pueden hacer herramientas Integradas (eso sería como ahora están las extensions) o en modo Isolate (esto es lo que nos vendría bien).

cómo se vería GXtest en VS Shell

cómo se vería GXtest en GeneXus Shell

De esta forma podríamos tener GXtest sobre el IDE de Genexus (esto trae otras ventajas pero no nos detendremos en eso en este post). La implementación sería más simple y consistente, ya que una sola implementación para las dos versiones (desarrollador y tester) que antes nombrabamos.